From dirk at haun-online.de  Fri May  1 13:43:48 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Fri, 1 May 2009 19:43:48 +0200
Subject: [geeklog-devel] 1.6.0b1 is out
Message-ID: <20090501174348.1641121724@smtp.haun-online.de>

If you haven't seen it yet: Geeklog 1.6.0b1 is finally out. Thanks to
everyone who has contributed to it, especially our GSoC 2008 students,
GSoC 2009 applicants, and "surprise guest" mystral-kk :)

We should now be concentrating on 2 things:

- bugfixes only (preferably any new ones that come up with this version)
- code reviews for security

In other words: No new features, please. A 1.6.1 probably isn't too far
behind anyway, but we should be concentrating on wrapping up 1.6.0 now
so that our GSoC students have a basis they can start working on.

bye, Dirk


-- 
http://www.geeklog.net/
http://geeklog.info/



From sc1245 at messiah.edu  Fri May  1 16:02:29 2009
From: sc1245 at messiah.edu (Sean Clark)
Date: Fri, 01 May 2009 16:02:29 -0400
Subject: [geeklog-devel] 1.6.0b1 is out
Message-ID: <49FB1D15020000CB0001C7EF@gwia.messiah.edu>

Hey Dirk, I noticed you mentioned no new features; I do have that GoogleBot
'nofollow' feature mostly implemented. It may be a week or so before I get
to completely check it, but should I wait until 1.6.1 to send this along?

Thanks,
Sean

>>> "Dirk Haun" <dirk at haun-online.de> 05/01/09 1:43 PM >>>
If you haven't seen it yet: Geeklog 1.6.0b1 is finally out. Thanks to
everyone who has contributed to it, especially our GSoC 2008 students,
GSoC 2009 applicants, and "surprise guest" mystral-kk :)

We should now be concentrating on 2 things:

- bugfixes only (preferably any new ones that come up with this version)
- code reviews for security

In other words: No new features, please. A 1.6.1 probably isn't too far
behind anyway, but we should be concentrating on wrapping up 1.6.0 now
so that our GSoC students have a basis they can start working on.

bye, Dirk


-- 
http://www.geeklog.net/
http://geeklog.info/

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://eight.pairlist.net/mailman/listinfo/geeklog-devel



From dirk at haun-online.de  Fri May  1 16:40:55 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Fri, 1 May 2009 22:40:55 +0200
Subject: [geeklog-devel] 1.6.0b1 is out
In-Reply-To: <49FB1D15020000CB0001C7EF@gwia.messiah.edu>
References: <49FB1D15020000CB0001C7EF@gwia.messiah.edu>
Message-ID: <20090501204055.1619275251@smtp.haun-online.de>

Sean Clark wrote:

>Hey Dirk, I noticed you mentioned no new features; I do have that GoogleBot
>'nofollow' feature mostly implemented. It may be a week or so before I get
>to completely check it, but should I wait until 1.6.1 to send this along?

I imagine this patch will be a bit invasive? So I think this should
wait. Actually, you would only have to wait until 1.6.0 is released, at
which point the repository will be open for enhancements again. In about
3 or 4 weeks, I would hope.

Btw, there were a few other patches from GSoC applicants that didn't
make it. Those are not forgotten and will be added later. Sorry about
that, but we have to draw a line somewhere. Trying to to add features at
the last minute will always carry the risk of introducing new problems
(as I realized again this morning, when I tried ramming the XMLSitemap
plugin into the release ...).

bye, Dirk


-- 
http://www.geeklog.net/
http://geeklog.info/



From dirk at haun-online.de  Sat May  9 09:26:43 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Sat, 9 May 2009 15:26:43 +0200
Subject: [geeklog-devel] The Geeklog Wiki needs YOUR help!
Message-ID: <20090509132643.653688770@smtp.haun-online.de>

The Geeklog Wiki, <http://wiki.geeklog.net/>, does contain a lot of
useful information, but probably wasn't exactly the most attractive
place to go to for help, mostly due to the duplicate documentation trees
(for 1.3 and 1.4). We've finally managed to merge these two trees back
together and get rid of (most) of the duplicate content.

This is now the point where we would welcome input and additions from
the Geeklog community. For example, there's a lot of content there
regarding development, but very little about the actual daily use of Geeklog.

Also, the installation instructions are in a state of disarray after an
attempt to merge the instructions from the two documentation trees -
both of which were out of date to begin with. I guess it would be best
to start over fresh here and describe the installation process as of
Geeklog 1.6. I wonder if anyone from outside the core team would be
interested in trying to write up new installation instructions in "plain
English"? Jason C. Levine did a good job at that a few years ago, but
the installation process has changed a lot since then and it's time for
a fresh start, IMO.

In the long run, I'd like the Geeklog Wiki to become the main source for
the Geeklog documentation. We will always ship some form of
documentation with Geeklog, but the wiki could become the master source
from which that documentation is fed and updated. And things like the
Plugin API and theme documentation should probably only live in the wiki.

So, if you ever thought about contributing to Geeklog but you couldn't
because you're not a programmer, here's an opportunity to help us out.
You will need an account for the wiki, but we're giving those out freely
(self registration is only disabled because of those pesky spammers).
Small contributions, such as clarifying sentences, correcting typos, or
adding links between existing pages are also very welcome.

bye, Dirk


-- 
http://www.geeklog.net/
http://geeklog.info/



From cordiste at free.fr  Sat May  9 11:38:04 2009
From: cordiste at free.fr (cordiste)
Date: Sat, 9 May 2009 17:38:04 +0200
Subject: [geeklog-devel] The Geeklog Wiki needs YOUR help!
In-Reply-To: <20090509132643.653688770@smtp.haun-online.de>
References: <20090509132643.653688770@smtp.haun-online.de>
Message-ID: <364575ed0905090838o5c33f4bey3483f054cd3090b8@mail.gmail.com>

Hello everybody,

Good news for the wiki. Just a question, if it is a kind of new start,
why don't we consider migrate to dokuwiki? We have the dokuwiki
plugin, an integration to Geeklog
http://www.geeklog.net/article.php/20090218063636626

Maybe it would be easier to manage contributors and very important
wiki pages would be include in the search function on geeklog.net. You
can see a demo page on http://geeklog.fr/wiki/doku.php/main-page made
with an online converter found on
http://johbuc6.coconia.net/doku.php/mediawiki_to_dokuwiki_converter

Thanks,

::Ben
Support and French community
http://geeklog.fr



2009/5/9 Dirk Haun <dirk at haun-online.de>:
> The Geeklog Wiki, <http://wiki.geeklog.net/>, does contain a lot of
> useful information, but probably wasn't exactly the most attractive
> place to go to for help, mostly due to the duplicate documentation trees
> (for 1.3 and 1.4). We've finally managed to merge these two trees back
> together and get rid of (most) of the duplicate content.
>
> This is now the point where we would welcome input and additions from
> the Geeklog community. For example, there's a lot of content there
> regarding development, but very little about the actual daily use of Geeklog.
>
> Also, the installation instructions are in a state of disarray after an
> attempt to merge the instructions from the two documentation trees -
> both of which were out of date to begin with. I guess it would be best
> to start over fresh here and describe the installation process as of
> Geeklog 1.6. I wonder if anyone from outside the core team would be
> interested in trying to write up new installation instructions in "plain
> English"? Jason C. Levine did a good job at that a few years ago, but
> the installation process has changed a lot since then and it's time for
> a fresh start, IMO.
>
> In the long run, I'd like the Geeklog Wiki to become the main source for
> the Geeklog documentation. We will always ship some form of
> documentation with Geeklog, but the wiki could become the master source
> from which that documentation is fed and updated. And things like the
> Plugin API and theme documentation should probably only live in the wiki.
>
> So, if you ever thought about contributing to Geeklog but you couldn't
> because you're not a programmer, here's an opportunity to help us out.
> You will need an account for the wiki, but we're giving those out freely
> (self registration is only disabled because of those pesky spammers).
> Small contributions, such as clarifying sentences, correcting typos, or
> adding links between existing pages are also very welcome.
>
> bye, Dirk
>
>
> --
> http://www.geeklog.net/
> http://geeklog.info/
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
>


From dirk at haun-online.de  Sat May  9 11:51:23 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Sat, 9 May 2009 17:51:23 +0200
Subject: [geeklog-devel] The Geeklog Wiki needs YOUR help!
In-Reply-To: <364575ed0905090838o5c33f4bey3483f054cd3090b8@mail.gmail.com>
References: <20090509132643.653688770@smtp.haun-online.de>
	<364575ed0905090838o5c33f4bey3483f054cd3090b8@mail.gmail.com>
Message-ID: <20090509155123.817394413@smtp.haun-online.de>

cordiste wrote:

>Just a question, if it is a kind of new start,
>why don't we consider migrate to dokuwiki?

The "fresh start" bit was only referring to the installation instructions.

bye, Dirk


-- 
http://www.geeklog.net/
http://geeklog.info/



From dirk at haun-online.de  Sat May 16 03:35:30 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Sat, 16 May 2009 09:35:30 +0200
Subject: [geeklog-devel] Plugin Repository Development Thread
Message-ID: <20090516073530.304963761@smtp.haun-online.de>

I feel like a few things are getting lost in the discussion[1] (probably
because some people jumped into it without reading the ideas page[2]
first). So let me point them out:

1) The plugin upload in 1.6.0 already takes care of moving the 3
standard directories around. Any additional files/directories needed by
the plugin can easily be moved in the plugin_postinstall function.

So I don't see a need for the proposed new configuration file - it can
all be done in the autoinstall.php[3] file already.

2) Not sure where the wget idea came from, but we already use PEAR's
HTTP_Request all over the place in Geeklog. I would think this would
then be the obvious choice for downloads here, too.

bye, Dirk

[1] <http://www.geeklog.net/forum/viewtopic.php?showtopic=87486>
[2] <http://wiki.geeklog.net/index.php/SoC_plugin_repository>
[3] <http://wiki.geeklog.net/index.php/Plugin_Autoinstall>


-- 
http://www.geeklog.net/
http://geeklog.info/



From dirk at haun-online.de  Sun May 17 03:00:52 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Sun, 17 May 2009 09:00:52 +0200
Subject: [geeklog-devel] Plugin Repository Development Thread
In-Reply-To: <20090516073530.304963761@smtp.haun-online.de>
References: <20090516073530.304963761@smtp.haun-online.de>
Message-ID: <20090517070052.1083387429@smtp.haun-online.de>

Something else we need to take care of in plugins: An indication which
databases are supported.

I would think it's the plugin's responsibility to check this upon
install (in the plugin_compatible_with_this_version function).

But it would be useful to have this information available in the Plugin
Repository, so that if you're running on Postgres and the plugin only
supports MS SQL, you don't need to download the plugin to find out.

Is this something the person uploading the plugin should provide in a
form or could this be found out automatically (since I assume the Plugin
Repository will perform certain checks automatically anyway)?

bye, Dirk


-- 
http://www.geeklog.net/
http://geeklog.info/



From joe at ThrowingDice.com  Sun May 17 09:49:40 2009
From: joe at ThrowingDice.com (Joe Mucchiello)
Date: Sun, 17 May 2009 09:49:40 -0400
Subject: [geeklog-devel] Plugin Repository Development Thread
In-Reply-To: <20090517070052.1083387429@smtp.haun-online.de>
References: <20090516073530.304963761@smtp.haun-online.de>
	<20090517070052.1083387429@smtp.haun-online.de>
Message-ID: <0KJS00HQ9JTHNYC0@mta1.srv.hcvlny.cv.net>

At 03:00 AM 5/17/2009, Dirk Haun wrote:
>Is this something the person uploading the plugin should provide in a
>form or could this be found out automatically (since I assume the Plugin
>Repository will perform certain checks automatically anyway)?

Assuming a standard setup, the plugin should have a SQL directory 
with files in the form {$_DB_dbms}_install.php: one for each 
supported database. Looking at some random plugins this is not always 
the case. mySql only plugins tend to just have install.php and some 
plugins have the form {$_DB_dbms}_install_{$pi_version}.php. So 
currently it is inexact. But since the repository changes a bunch of 
other things, there's no reason not to have a standard filename 
format for database support purposes.



----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com 



From tcsp1900 at hotmail.com  Sun May 17 11:23:27 2009
From: tcsp1900 at hotmail.com (Tim Patrick)
Date: Sun, 17 May 2009 11:23:27 -0400
Subject: [geeklog-devel] geeklog-devel Digest, Vol 28, Issue 5
In-Reply-To: <mailman.5.1242568802.95828.geeklog-devel@lists.geeklog.net>
References: <mailman.5.1242568802.95828.geeklog-devel@lists.geeklog.net>
Message-ID: <BAY109-W166D719E118690DB48F57CD35D0@phx.gbl>


Ideally of course this would be put in a config file.
However, I would assume that this could be found out based on the fact that it looks to me (correct me if I am wrong) that all plugins tend to have the SQL folder in them, with a file for each database supported.
Hence it could probably be found out this way. However it would be a better practice to enforce a file with this information (as well as other) to help standardize the process. Or maybe when they upload to the repository they can fill in a field for the supported databases (the best way) and if they do not fill in any it would then do a check to see if it can find any information, and failing finding anything display for that plugin that the db cannot be determined.

My idea is that the repository will contain information in it about each plugin that the plugin repository reads and then determines whether it can be installed on their server or not. (Much like how the firefox addons determines the version of firefox and won't let you install one that isn't for your version or supports it).

So if the server uses MSSQL the plugin repository would grey out any entries that did not support MSSQL for auto install, however you could still download the plugin manually (in case you want to be able to hack it to work on MySQL for example :P)

- Tim

_________________________________________________________________
One at a time or all at once? Get updates from your friends in one place.
http://go.microsoft.com/?linkid=9660827
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20090517/9496c274/attachment.html>

From dirk at haun-online.de  Sun May 17 11:51:42 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Sun, 17 May 2009 17:51:42 +0200
Subject: [geeklog-devel] geeklog-devel Digest, Vol 28, Issue 5
In-Reply-To: <BAY109-W166D719E118690DB48F57CD35D0@phx.gbl>
References: <mailman.5.1242568802.95828.geeklog-devel@lists.geeklog.net>
	<BAY109-W166D719E118690DB48F57CD35D0@phx.gbl>
Message-ID: <20090517155142.988923163@smtp.haun-online.de>

Tim Patrick wrote:

>However, I would assume that this could be found out based on the fact
>that it looks to me (correct me if I am wrong) that all plugins tend to
>have the SQL folder in them, with a file for each database supported.

That's how I implemented it now[1] for the bundled plugins. Of course,
that only works for a plugin you have control over, not in the generic
case. A plugin could not have an "sql" directory and still support MS SQL.

So that information must come from somewhere.


>However it would be a better practice to enforce a file with this
>information (as well as other) to help standardize the process.

Not saying it's the best way, but have you considered adding this
information to the autoinstall.php? I would assume the Plugin Repository
could load it anyway to get the plugin's name and version number.

The downside of this: It's a huge security hole ...

bye, Dirk

[1] <http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/rev/9089a0c77860>


-- 
http://www.geeklog.net/
http://geeklog.info/



From tcsp1900 at hotmail.com  Mon May 18 21:57:48 2009
From: tcsp1900 at hotmail.com (Tim Patrick)
Date: Mon, 18 May 2009 21:57:48 -0400
Subject: [geeklog-devel] geeklog-devel Digest, Vol 28, Issue 6
In-Reply-To: <mailman.11.1242655203.29081.geeklog-devel@lists.geeklog.net>
References: <mailman.11.1242655203.29081.geeklog-devel@lists.geeklog.net>
Message-ID: <BAY109-W29AC4DAE910822CACDA8BED35B0@phx.gbl>


I will be gone to PEI from tomorrow till saturday for a web design contest and I may have internet or not, but if I do not reply that will be why. I will do my best to get some connectivity :)

- Tim

_________________________________________________________________
Windows Live helps you keep up with all your friends, in one place.
http://go.microsoft.com/?linkid=9660826
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20090518/c50bf512/attachment.html>

From dirk at haun-online.de  Thu May 21 04:20:54 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Thu, 21 May 2009 10:20:54 +0200
Subject: [geeklog-devel] Mercurial 1.2.1
Message-ID: <20090521082054.1446445645@smtp.haun-online.de>

The Mercurial install on cvs.geeklog.net has been updated to version
1.2.1. While Mercurial is actually pretty good at being both backward
and forward compatible, I recommend that everybody upgrade their local
install to that version as well, just to be on the safe side.

I'm also planning on using one of the new features to close old branches
and I'm not entirely sure how pre-1.2 clients will react to that ...

bye, Dirk


-- 
http://www.haun-online.de/
http://spam.tinyweb.net/



From dirk at haun-online.de  Thu May 28 16:42:19 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Thu, 28 May 2009 22:42:19 +0200
Subject: [geeklog-devel] Updating a plugin in the Plugin Repository
Message-ID: <20090528204219.149629853@smtp.haun-online.de>

Tim asked about this on IRC and we decided to move the discussion here.

So say you already have a plugin in the Plugin Repository. Now someone
(the developer or an admin) wants to update it. How would that work?

My take is to model this somewhat after how the File Management plugin
does it (minus the bugs):

- Click on an "Edit" link
- You can now edit the description and select a new file for upload
- Click "update"

What happens then depends on a variety of options we talked about
before, e.g. is the person allowed to update the plugin directly or does
it have to go through re-approval by a moderator?

If it goes into the moderation queue, you should still be able to
download the old version until the update is approved. So you would need
two db entries (which you would need anyway, if you're using the
Moderation API).

Who can replace a file? A "Plugin Repository Admin" in any case. And if
you allow public uploads (as, say, on geeklog.net) then anybody should
be able to submit an update. Plugins may change ownership or two people
may be working on a plugin, etc., so I don't see a reason to restrict that.

Also, it shouldn't require that the newly uploaded file has a different
filename than the old version (as the File Management plugin does - I
consider this a bug). Preferrably, the file name would be editable
without having to re-upload the file (typos happen ...).

Did I forget anything?

bye, Dirk

P.S. Tim, if you haven't done so already, I'd suggest you have a look at
the File Management, at least from the workflow / UI point of view.


-- 
http://www.geeklog.net/
http://geeklog.info/



From dirk at haun-online.de  Thu May 28 16:45:06 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Thu, 28 May 2009 22:45:06 +0200
Subject: [geeklog-devel] Fwd:  MSSQL Class - SQL Coding
Message-ID: <20090528204506.317262871@smtp.haun-online.de>

I dug out Randy's old post (below) for Tim, who asked for advice on
writing DBMS-agnostic SQL requests.

Shouldn't this be on the wiki? It could serve as the basis for a "guide
on writing SQL requests", to which Stan would surely want to add a few
Postgres Gotchas ...

---------------- Anfang Weiterleitung ----------------
Betreff: [geeklog-devel] MSSQL Class - SQL Coding 
Gesendet: Donnerstag, 23. M?rz 2006 8:53 Uhr
Von: Randy Kolenko <randy at nextide.ca>
An: geeklog-devel at lists.geeklog.net


"GOTCHAs" within GL and plugin SQL coding:

- Stray away from DB_save.  Use the appropritate Update or Insert statements
as necessary.  Although this works in the MSSQL class, its not a standard
SQL call.

-Avoid REPLACE INTO at all costs.  While DB_save approximates this
functionality, it only uses one primary key to match the incoming columns
and data against rather than ALL incoming primary key columns.  Just use an
update or delete + insert combination to perform the REPLACE INTO
functionality.

-While very handy, LIMIT is not a standard sql statement.  However a
statement such as :
      select * from table LIMIT 1
will be translated into:
      selet TOP 1 * from table
And will not incurr any in-code overhead to approximate the limit command.

LIMIT-ing your result sets like this:
     select * from table LIMIT 100,10
to pick off the 100th to 109th rows is absolutelly not supported by sql
server and there is no equivalent.  While handy for paging, the LIMIT
approximation for this scenario is handled in the MSSQL class code and thus
may not perform as quickly on extremely LARGE result sets.

-Ensure all selected columns show up in the group by clause - there are a
few instances of missing columns in group by clauses.  Mysql is a little
more forgiving than SQL server is.

- Note that '' (single quotes with nothing between them) does not represent
NULL in SQL server. The triggers I've implemented are to cleanse any data
that appears to be null and replace the empty varchar data with NULL.  This
way, when PHP tests empty() on a column, it returns empty properly.


_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel


----------------- Ende Weiterleitung -----------------

-- 
http://www.geeklog.net/
http://geeklog.info/



From yankees26an at gmail.com  Thu May 28 17:16:32 2009
From: yankees26an at gmail.com (=?UTF-8?B?yJjPruKxpci10ZbhuaXKn8mR4oia?=)
Date: Thu, 28 May 2009 17:16:32 -0400
Subject: [geeklog-devel] Fwd: MSSQL Class - SQL Coding
In-Reply-To: <20090528204506.317262871@smtp.haun-online.de>
References: <20090528204506.317262871@smtp.haun-online.de>
Message-ID: <7aaf88900905281416q10390db7x5e16ab22e3bb2408@mail.gmail.com>

Hey,

Just of the top of my head, a nice thing to do would be to pass the sql to
dbError(). If you don't, then pgSQL will have to run an extra function call
to sniff out the last execution query, which wastes some precious cycles.

Also you should preferably use timestamp instead of datetime because
timestamp is ansi sql, while datetime is MySQL's little invention. :P

Those two things arent critical, but the next one is, which has been
mentioned..

Avoid any variations of REPLACE like the plague. Seriously :P It's only
supported by MySQL, and while it may make MySQL queries a hair faster, it
will make msssql and pgsql queries alot slower because they dont support it.


Your best bet is to just code ANSI SQL compliant code. If you've only been
used to Mysql, it can be very tempting to cheat, but it will pay off in the
end ;)

On Thu, May 28, 2009 at 4:45 PM, Dirk Haun <dirk at haun-online.de> wrote:

> I dug out Randy's old post (below) for Tim, who asked for advice on
> writing DBMS-agnostic SQL requests.
>
> Shouldn't this be on the wiki? It could serve as the basis for a "guide
> on writing SQL requests", to which Stan would surely want to add a few
> Postgres Gotchas ...
>
> ---------------- Anfang Weiterleitung ----------------
> Betreff: [geeklog-devel] MSSQL Class - SQL Coding
> Gesendet: Donnerstag, 23. M?rz 2006 8:53 Uhr
> Von: Randy Kolenko <randy at nextide.ca>
> An: geeklog-devel at lists.geeklog.net
>
>
> "GOTCHAs" within GL and plugin SQL coding:
>
> - Stray away from DB_save.  Use the appropritate Update or Insert
> statements
> as necessary.  Although this works in the MSSQL class, its not a standard
> SQL call.
>
> -Avoid REPLACE INTO at all costs.  While DB_save approximates this
> functionality, it only uses one primary key to match the incoming columns
> and data against rather than ALL incoming primary key columns.  Just use an
> update or delete + insert combination to perform the REPLACE INTO
> functionality.
>
> -While very handy, LIMIT is not a standard sql statement.  However a
> statement such as :
>      select * from table LIMIT 1
> will be translated into:
>      selet TOP 1 * from table
> And will not incurr any in-code overhead to approximate the limit command.
>
> LIMIT-ing your result sets like this:
>     select * from table LIMIT 100,10
> to pick off the 100th to 109th rows is absolutelly not supported by sql
> server and there is no equivalent.  While handy for paging, the LIMIT
> approximation for this scenario is handled in the MSSQL class code and thus
> may not perform as quickly on extremely LARGE result sets.
>
> -Ensure all selected columns show up in the group by clause - there are a
> few instances of missing columns in group by clauses.  Mysql is a little
> more forgiving than SQL server is.
>
> - Note that '' (single quotes with nothing between them) does not represent
> NULL in SQL server. The triggers I've implemented are to cleanse any data
> that appears to be null and replace the empty varchar data with NULL.  This
> way, when PHP tests empty() on a column, it returns empty properly.
>
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>
>
> ----------------- Ende Weiterleitung -----------------
>
> --
> http://www.geeklog.net/
> http://geeklog.info/
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>



-- 
Warmly,

Stanislav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20090528/4fe60c91/attachment.html>

From vfuria at gmail.com  Thu May 28 18:43:59 2009
From: vfuria at gmail.com (Vincent Furia)
Date: Thu, 28 May 2009 16:43:59 -0600
Subject: [geeklog-devel] Updating a plugin in the Plugin Repository
In-Reply-To: <20090528204219.149629853@smtp.haun-online.de>
References: <20090528204219.149629853@smtp.haun-online.de>
Message-ID: <8319e2d60905281543k39c60979y282d9acd87a0c579@mail.gmail.com>

I think it would be nice if we could somehow version the files in the plugin
repository. That way if you running a 1.6.x Geeklog site (still supported)
but the updated plugin uses features (plugin APIs, etc) only 1.7.x you can
run/download/install the old version (for instance if your site is lost and
you are recovering it from backups).

Then you could have the plugin repository admin mark some versions as
depreciated or insecure or even unavailable.

I do wholeheartedly agree with this:

> - Click on an "Edit" link
> - You can now edit the description and select a new file for upload
> - Click "update"
>
> What happens then depends on a variety of options we talked about
> before, e.g. is the person allowed to update the plugin directly or does
> it have to go through re-approval by a moderator?
>
> If it goes into the moderation queue, you should still be able to
> download the old version until the update is approved. So you would need
> two db entries (which you would need anyway, if you're using the
> Moderation API).



Also, it shouldn't require that the newly uploaded file has a different
> filename than the old version (as the File Management plugin does - I
> consider this a bug). Preferrably, the file name would be editable
> without having to re-upload the file (typos happen ...).

You should be able to write a "download.php" file that grabs the file off
the file system but causes the downloaded file name to be whatever is set in
the database. That would allow for non-unique filenames. The files on the
system could simply be named for the plugin repository id they are
associated and a unique number (i.e. calendar-0001.tar.gz). Then when it
gets downloaded it can be calendar_0.1_1.6.0.tar.gz. Using a download.php
would have the added advantage of being able to keep old files around and
still restrict downloads of them.



> Did I forget anything?

I don't think so, but I do think I need to hang out on IRC more. :)

-Vinny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20090528/ab29d759/attachment.html>

From furiousdog at gmail.com  Fri May 29 08:51:11 2009
From: furiousdog at gmail.com (Sami Barakat)
Date: Fri, 29 May 2009 13:51:11 +0100
Subject: [geeklog-devel] Fwd: MSSQL Class - SQL Coding
In-Reply-To: <7aaf88900905281416q10390db7x5e16ab22e3bb2408@mail.gmail.com>
References: <20090528204506.317262871@smtp.haun-online.de> 
	<7aaf88900905281416q10390db7x5e16ab22e3bb2408@mail.gmail.com>
Message-ID: <609505460905290551r186b08c6u5d7f63efd3da3619@mail.gmail.com>

Just a rather random idea that poped into my head (but will probably
be too hard to implement....)

If you are wanting to add support for various databases why not take
the same approach as support for languages. Say for instance the
english language file has all the strings set to variable which are
then used in the code. When wanting to make a translation you just
copy this file and start translating. The core will then pick up the
new language file and use that. The same may be possible for sql
strings. Then when support is added for a new database all that needs
to be done is translate the file to the required syntax for that
database and create the database class. Is this even possible?

Geeklog is probably too far down the line to even try to implement
this as its a very large change not only to the core but to all the
plugins. But just an idea...

Sami

2009/5/28 ????????? <yankees26an at gmail.com>:
> Hey,
>
> Just of the top of my head, a nice thing to do would be to pass the sql to
> dbError(). If you don't, then pgSQL will have to run an extra function call
> to sniff out the last execution query, which wastes some precious cycles.
> Also you should preferably use timestamp instead of datetime because
> timestamp is ansi sql, while datetime is MySQL's little invention. :P
> Those two things arent critical, but the next one is, which has been
> mentioned..
> Avoid any variations of REPLACE like the plague. Seriously :P It's only
> supported by MySQL, and while it may make MySQL queries a hair faster, it
> will make msssql and pgsql queries alot slower because they dont support it.
>
> Your best bet is to just code ANSI SQL compliant code. If you've only been
> used to Mysql, it can be very tempting to cheat, but it will pay off in the
> end ;)
> On Thu, May 28, 2009 at 4:45 PM, Dirk Haun <dirk at haun-online.de> wrote:
>>
>> I dug out Randy's old post (below) for Tim, who asked for advice on
>> writing DBMS-agnostic SQL requests.
>>
>> Shouldn't this be on the wiki? It could serve as the basis for a "guide
>> on writing SQL requests", to which Stan would surely want to add a few
>> Postgres Gotchas ...
>>
>> ---------------- Anfang Weiterleitung ----------------
>> Betreff: [geeklog-devel] MSSQL Class - SQL Coding
>> Gesendet: Donnerstag, 23. M?rz 2006 8:53 Uhr
>> Von: Randy Kolenko <randy at nextide.ca>
>> An: geeklog-devel at lists.geeklog.net
>>
>>
>> "GOTCHAs" within GL and plugin SQL coding:
>>
>> - Stray away from DB_save. ?Use the appropritate Update or Insert
>> statements
>> as necessary. ?Although this works in the MSSQL class, its not a standard
>> SQL call.
>>
>> -Avoid REPLACE INTO at all costs. ?While DB_save approximates this
>> functionality, it only uses one primary key to match the incoming columns
>> and data against rather than ALL incoming primary key columns. ?Just use
>> an
>> update or delete + insert combination to perform the REPLACE INTO
>> functionality.
>>
>> -While very handy, LIMIT is not a standard sql statement. ?However a
>> statement such as :
>> ? ? ?select * from table LIMIT 1
>> will be translated into:
>> ? ? ?selet TOP 1 * from table
>> And will not incurr any in-code overhead to approximate the limit command.
>>
>> LIMIT-ing your result sets like this:
>> ? ? select * from table LIMIT 100,10
>> to pick off the 100th to 109th rows is absolutelly not supported by sql
>> server and there is no equivalent. ?While handy for paging, the LIMIT
>> approximation for this scenario is handled in the MSSQL class code and
>> thus
>> may not perform as quickly on extremely LARGE result sets.
>>
>> -Ensure all selected columns show up in the group by clause - there are a
>> few instances of missing columns in group by clauses. ?Mysql is a little
>> more forgiving than SQL server is.
>>
>> - Note that '' (single quotes with nothing between them) does not
>> represent
>> NULL in SQL server. The triggers I've implemented are to cleanse any data
>> that appears to be null and replace the empty varchar data with NULL.
>> ?This
>> way, when PHP tests empty() on a column, it returns empty properly.
>>
>>
>> _______________________________________________
>> geeklog-devel mailing list
>> geeklog-devel at lists.geeklog.net
>> http://lists.geeklog.net/listinfo/geeklog-devel
>>
>>
>> ----------------- Ende Weiterleitung -----------------
>>
>> --
>> http://www.geeklog.net/
>> http://geeklog.info/
>>
>> _______________________________________________
>> geeklog-devel mailing list
>> geeklog-devel at lists.geeklog.net
>> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
>
>
> --
> Warmly,
>
> Stanislav
>
>
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
>


From Randy.Kolenko at nextide.ca  Fri May 29 08:55:30 2009
From: Randy.Kolenko at nextide.ca (Randy Kolenko)
Date: Fri, 29 May 2009 08:55:30 -0400
Subject: [geeklog-devel] Fwd: MSSQL Class - SQL Coding
Message-ID: <063B8B70CB9DA141B2FC1DB483561B9F26A956@nex-pluto.nextide.ca>

In the long run:

http://www.geeklog.net/filemgmt/index.php?id=757
Write new plugins with a database abstraction layer.


Failing that, writing simple standard/portable sql should probably be sufficient for 95% of the plugins out there.

We also have the ability to do an array with the key as the db layer
$sql['mssql'] 
$sql['mysql'] to differentiate different sql statements -- so this will have to be checked in to for improvements when postgres goes into play.

-randy



> -----Original Message-----
> From: Sami Barakat [mailto:furiousdog at gmail.com] 
> Sent: May-29-09 8:51 AM
> To: Geeklog Development
> Subject: Re: [geeklog-devel] Fwd: MSSQL Class - SQL Coding
> 
> 
> Just a rather random idea that poped into my head (but will 
> probably be too hard to implement....)
> 
> If you are wanting to add support for various databases why 
> not take the same approach as support for languages. Say for 
> instance the english language file has all the strings set to 
> variable which are then used in the code. When wanting to 
> make a translation you just copy this file and start 
> translating. The core will then pick up the new language file 
> and use that. The same may be possible for sql strings. Then 
> when support is added for a new database all that needs to be 
> done is translate the file to the required syntax for that 
> database and create the database class. Is this even possible?
> 
> Geeklog is probably too far down the line to even try to 
> implement this as its a very large change not only to the 
> core but to all the plugins. But just an idea...
> 
> Sami
> 
> 2009/5/28 ????????? <yankees26an at gmail.com>:
> > Hey,
> >
> > Just of the top of my head, a nice thing to do would be to pass the 
> > sql to dbError(). If you don't, then pgSQL will have to run 
> an extra 
> > function call to sniff out the last execution query, which 
> wastes some 
> > precious cycles. Also you should preferably use timestamp 
> instead of 
> > datetime because timestamp is ansi sql, while datetime is MySQL's 
> > little invention. :P Those two things arent critical, but 
> the next one 
> > is, which has been mentioned.. Avoid any variations of REPLACE like 
> > the plague. Seriously :P It's only supported by MySQL, and while it 
> > may make MySQL queries a hair faster, it will make msssql and pgsql 
> > queries alot slower because they dont support it.
> >
> > Your best bet is to just code ANSI SQL compliant code. If 
> you've only 
> > been used to Mysql, it can be very tempting to cheat, but 
> it will pay 
> > off in the end ;) On Thu, May 28, 2009 at 4:45 PM, Dirk Haun 
> > <dirk at haun-online.de> wrote:
> >>
> >> I dug out Randy's old post (below) for Tim, who asked for 
> advice on 
> >> writing DBMS-agnostic SQL requests.
> >>
> >> Shouldn't this be on the wiki? It could serve as the basis for a 
> >> "guide on writing SQL requests", to which Stan would 
> surely want to 
> >> add a few Postgres Gotchas ...
> >>
> >> ---------------- Anfang Weiterleitung ----------------
> >> Betreff: [geeklog-devel] MSSQL Class - SQL Coding
> >> Gesendet: Donnerstag, 23. M?rz 2006 8:53 Uhr
> >> Von: Randy Kolenko <randy at nextide.ca>
> >> An: geeklog-devel at lists.geeklog.net
> >>
> >>
> >> "GOTCHAs" within GL and plugin SQL coding:
> >>
> >> - Stray away from DB_save. ?Use the appropritate Update or Insert 
> >> statements as necessary. ?Although this works in the MSSQL 
> class, its 
> >> not a standard SQL call.
> >>
> >> -Avoid REPLACE INTO at all costs. ?While DB_save approximates this 
> >> functionality, it only uses one primary key to match the incoming 
> >> columns and data against rather than ALL incoming primary key 
> >> columns. ?Just use an update or delete + insert combination to 
> >> perform the REPLACE INTO functionality.
> >>
> >> -While very handy, LIMIT is not a standard sql statement. ?
However a 
> >> statement such as :
> >> ? ? ?select * from table LIMIT 1
> >> will be translated into:
> >> ? ? ?selet TOP 1 * from table
> >> And will not incurr any in-code overhead to approximate the limit 
> >> command.
> >>
> >> LIMIT-ing your result sets like this:
> >> ? ? select * from table LIMIT 100,10
> >> to pick off the 100th to 109th rows is absolutelly not 
> supported by 
> >> sql server and there is no equivalent. ?While handy for 
> paging, the 
> >> LIMIT approximation for this scenario is handled in the 
> MSSQL class 
> >> code and thus may not perform as quickly on extremely LARGE result 
> >> sets.
> >>
> >> -Ensure all selected columns show up in the group by 
> clause - there 
> >> are a few instances of missing columns in group by 
> clauses. ?Mysql is 
> >> a little more forgiving than SQL server is.
> >>
> >> - Note that '' (single quotes with nothing between them) does not 
> >> represent NULL in SQL server. The triggers I've implemented are to 
> >> cleanse any data that appears to be null and replace the empty 
> >> varchar data with NULL.
> >> ?This
> >> way, when PHP tests empty() on a column, it returns empty properly.
> >>
> >>
> >> _______________________________________________
> >> geeklog-devel mailing list
> >> geeklog-devel at lists.geeklog.net 
> >> http://lists.geeklog.net/listinfo/geeklog-devel
> >>
> >>
> >> ----------------- Ende Weiterleitung -----------------
> >>
> >> --
> >> http://www.geeklog.net/
> >> http://geeklog.info/
> >>
> >> _______________________________________________
> >> geeklog-devel mailing list
> >> geeklog-devel at lists.geeklog.net 
> >> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
> >
> >
> >
> > --
> > Warmly,
> >
> > Stanislav
> >
> >
> >
> > _______________________________________________
> > geeklog-devel mailing list
> > geeklog-devel at lists.geeklog.net 
> > http://eight.pairlist.net/mailman/listinfo/geeklog-devel
> >
> >
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net 
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
> 

From matt.danger.west at gmail.com  Fri May 29 09:20:08 2009
From: matt.danger.west at gmail.com (Matt West)
Date: Fri, 29 May 2009 09:20:08 -0400
Subject: [geeklog-devel] Updating a plugin in the Plugin Repository
In-Reply-To: <8319e2d60905281543k39c60979y282d9acd87a0c579@mail.gmail.com>
References: <20090528204219.149629853@smtp.haun-online.de>
	<8319e2d60905281543k39c60979y282d9acd87a0c579@mail.gmail.com>
Message-ID: <84035F3D-B298-44C5-AB22-9E87BD11207C@gmail.com>

On May 28, 2009, at 6:43 PM, Vincent Furia wrote:

> I think it would be nice if we could somehow version the files in  
> the plugin repository. That way if you running a 1.6.x Geeklog site  
> (still supported) but the updated plugin uses features (plugin APIs,  
> etc) only 1.7.x you can run/download/install the old version (for  
> instance if your site is lost and you are recovering it from backups).
>
> Then you could have the plugin repository admin mark some versions  
> as depreciated or insecure or even unavailable.

Tim had suggested something like this and I actually discouraged him  
with the reasoning that it wouldn't be used much. The more I think of  
it now, it is a good idea. We were thinking in terms of different  
development versions (alpha, beta, final, etc), not final releases,  
though.

It shouldn't be up to the repository admin to mark the plugins as  
deprecated, et all, though. That's something the plugin developer  
would know best.


> You should be able to write a "download.php" file that grabs the  
> file off the file system but causes the downloaded file name to be  
> whatever is set in the database. That would allow for non-unique  
> filenames. The files on the system could simply be named for the  
> plugin repository id they are associated and a unique number (i.e.  
> calendar-0001.tar.gz). Then when it gets downloaded it can be  
> calendar_0.1_1.6.0.tar.gz. Using a download.php would have the added  
> advantage of being able to keep old files around and still restrict  
> downloads of them.

I'm on board with this.


> I don't think so, but I do think I need to hang out on IRC more. :)
>
> -Vinny

No_uO was missing you last night :)

Matt


From tcsp1900 at hotmail.com  Fri May 29 09:30:26 2009
From: tcsp1900 at hotmail.com (Tim Patrick)
Date: Fri, 29 May 2009 09:30:26 -0400
Subject: [geeklog-devel] geeklog-devel Digest, Vol 28, Issue 9
In-Reply-To: <mailman.1004.1243601492.76679.geeklog-devel@lists.geeklog.net>
References: <mailman.1004.1243601492.76679.geeklog-devel@lists.geeklog.net>
Message-ID: <BAY109-W28E4072092B8972B727F32D3510@phx.gbl>


Thanks for your feedback all!

Just a clarification, about the download saved on the disk as a different name and then when downloaded taken the name from the database and version.

The plugins will be stored on the server as pluginName_version#.extension.

Multiple plugins with the same name just tends to confuse people. 
Hence if the name already exists, either there is no point in creating a duplicate plugin (eg. Calendar and Calendar) or name it something that says a little bit more about that plugin, eg. company_wide_calendar.

As well, I think the repository files should also be able to be accessed directly by their folder (eg. MySite.com/repository/myplugin.tar.gz) instead of having to go to a download page.

- Tim

_________________________________________________________________
Find info faster and easier with Internet Explorer 8.
http://go.microsoft.com/?linkid=9655583
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20090529/2093e593/attachment.html>

From matt.danger.west at gmail.com  Fri May 29 09:10:50 2009
From: matt.danger.west at gmail.com (Matt West)
Date: Fri, 29 May 2009 09:10:50 -0400
Subject: [geeklog-devel] Updating a plugin in the Plugin Repository
In-Reply-To: <20090528204219.149629853@smtp.haun-online.de>
References: <20090528204219.149629853@smtp.haun-online.de>
Message-ID: <D9ED46BC-244C-4CF3-B04A-FBDE4645E44B@gmail.com>

On May 28, 2009, at 4:42 PM, Dirk Haun wrote:

> Tim asked about this on IRC and we decided to move the discussion  
> here.
>
> So say you already have a plugin in the Plugin Repository. Now someone
> (the developer or an admin) wants to update it. How would that work?
>
> My take is to model this somewhat after how the File Management plugin
> does it (minus the bugs):
>
> - Click on an "Edit" link
> - You can now edit the description and select a new file for upload
> - Click "update"
>
> What happens then depends on a variety of options we talked about
> before, e.g. is the person allowed to update the plugin directly or  
> does
> it have to go through re-approval by a moderator?
>
> If it goes into the moderation queue, you should still be able to
> download the old version until the update is approved. So you would  
> need
> two db entries (which you would need anyway, if you're using the
> Moderation API).
>
> Who can replace a file? A "Plugin Repository Admin" in any case. And  
> if
> you allow public uploads (as, say, on geeklog.net) then anybody should
> be able to submit an update. Plugins may change ownership or two  
> people
> may be working on a plugin, etc., so I don't see a reason to  
> restrict that.
>
> Also, it shouldn't require that the newly uploaded file has a  
> different
> filename than the old version (as the File Management plugin does - I
> consider this a bug). Preferrably, the file name would be editable
> without having to re-upload the file (typos happen ...).

I think the method you suggested would work well. Have we decided if  
we're supporting multiple plugin "owners/maintainers" or just one? I  
think we should support multiple. We could keep a list of  
"maintainers" for each plugin that could be defined both when the  
plugin is first uploaded and edited later.

As far as moderation, maybe let that be determined with a moderation  
setting in the repository's configuration:
- Require moderation for all updated plugins.
- Don't require moderation for updated plugins, allow plugin owners  
and maintainers complete control.

I think we should apply these same requirements for deleting plugins.

Matt


From tcsp1900 at hotmail.com  Fri May 29 10:07:01 2009
From: tcsp1900 at hotmail.com (Tim Patrick)
Date: Fri, 29 May 2009 10:07:01 -0400
Subject: [geeklog-devel] geeklog-devel Digest, Vol 28, Issue 10
In-Reply-To: <mailman.1.1243605603.93508.geeklog-devel@lists.geeklog.net>
References: <mailman.1.1243605603.93508.geeklog-devel@lists.geeklog.net>
Message-ID: <BAY109-W27536CF7D90C3D96933B2AD3510@phx.gbl>


Damn you matt changing your mind :P :P



_________________________________________________________________
One at a time or all at once? Get updates from your friends in one place.
http://go.microsoft.com/?linkid=9660827
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20090529/b4a330c2/attachment.html>

From tcsp1900 at hotmail.com  Fri May 29 10:11:13 2009
From: tcsp1900 at hotmail.com (Tim Patrick)
Date: Fri, 29 May 2009 10:11:13 -0400
Subject: [geeklog-devel] geeklog-devel Digest, Vol 28, Issue 10
In-Reply-To: <mailman.1.1243605603.93508.geeklog-devel@lists.geeklog.net>
References: <mailman.1.1243605603.93508.geeklog-devel@lists.geeklog.net>
Message-ID: <BAY109-W31047907BD68B9F9E4C89ED3510@phx.gbl>



_________________________________________________________________
Find info faster and easier with Internet Explorer 8.
http://go.microsoft.com/?linkid=9655583

From joe at ThrowingDice.com  Fri May 29 20:51:43 2009
From: joe at ThrowingDice.com (Joe Mucchiello)
Date: Fri, 29 May 2009 20:51:43 -0400
Subject: [geeklog-devel] Fwd: MSSQL Class - SQL Coding
In-Reply-To: <7aaf88900905281416q10390db7x5e16ab22e3bb2408@mail.gmail.co m>
References: <20090528204506.317262871@smtp.haun-online.de>
	<7aaf88900905281416q10390db7x5e16ab22e3bb2408@mail.gmail.com>
Message-ID: <0KKF009RNMBQ6770@mta5.srv.hcvlny.cv.net>

If I may make a suggestion, lib-database (and the database classes 
obviously) should help support SQL construction. Currently, for 
example, if you want to include mySQL's NOW() function in a query, 
you need to code the query for mssql with GETDATE() instead. It would 
be nice if lib-database provided some helper functions to remove the 
need to do the $sql['mysql'] thing at all. Instead you would say:

$sql = ..... DB_function('now') .....

or something to format dates correctly:

$sql = ...... DB_date($timestamp) ....

Obviously this is something that would need to planned for 1.7 I 
guess. But this would be make database agnostic coding much easier in 
the future. The trick is identifying what parts are different across 
various versions of SQL and making functions for them without knowing 
what future dialects will exist.

Also, I don't recommend this for the DDL. Every RDBMS has its own 
nearly unique DDL that it just isn't worth it. That's why plugins 
have different files for each database.

I still want to know how the pgsql layer is going to handle big text fields....

----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com 



No virus found in this outgoing message
Checked by PC Tools AntiVirus (6.0.0.19 - 10.004.038).
http://www.pctools.com/free-antivirus/


From dirk at haun-online.de  Sat May 30 15:11:12 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Sat, 30 May 2009 21:11:12 +0200
Subject: [geeklog-devel] Fwd: MSSQL Class - SQL Coding
In-Reply-To: <063B8B70CB9DA141B2FC1DB483561B9F26A956@nex-pluto.nextide.ca>
References: <063B8B70CB9DA141B2FC1DB483561B9F26A956@nex-pluto.nextide.ca>
Message-ID: <20090530191112.733514496@smtp.haun-online.de>

I dumped this information into the wiki now:

    http://wiki.geeklog.net/index.php/Writing_Portable_SQL

Maybe somebody who knows more about SQL than I do (= pretty much
everybody else on this list) could expand it so that it actually
contains what the page title implies?

bye, Dirk


-- 
http://www.geeklog.net/
http://geeklog.info/



From joe at ThrowingDice.com  Sat May 30 15:29:09 2009
From: joe at ThrowingDice.com (Joe Mucchiello)
Date: Sat, 30 May 2009 15:29:09 -0400
Subject: [geeklog-devel] Fwd: MSSQL Class - SQL Coding
In-Reply-To: <20090530191112.733514496@smtp.haun-online.de>
References: <063B8B70CB9DA141B2FC1DB483561B9F26A956@nex-pluto.nextide.ca>
	<20090530191112.733514496@smtp.haun-online.de>
Message-ID: <0KKH005N0223AP40@mta2.srv.hcvlny.cv.net>


>Note that '' (single quotes with nothing between them) does not 
>represent NULL in SQL Server. The triggers I've implemented are to 
>cleanse any data that appears to be NULL and replace the empty 
>VARCHAR data with NULL. This way, when PHP tests empty() on a 
>column, it returns empty properly.

I don't understand this. empty($var) returns true if $var is '', 0, 
"0", 0.0, false, array(), or null. Why do you need to do this? Are 
you talking about on the way into SQL Server or on the way out?

>Use of the array notation (see above) is recommended instead of 
>checking the content of $_DB_dbms when writing DBMS-specific SQL request.

I still don't like this for one reason. The code for both (and soon 
all three) array values executes but only one of the results is 
needed. This is the other reason I think a set of functions would work better.

----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com 



No virus found in this outgoing message
Checked by PC Tools AntiVirus (6.0.0.19 - 10.004.038).
http://www.pctools.com/free-antivirus/


From dirk at haun-online.de  Sun May 31 13:02:06 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Sun, 31 May 2009 19:02:06 +0200
Subject: [geeklog-devel] Mercurial and line endings
In-Reply-To: <20090117221800.1387857041@smtp.haun-online.de>
References: <20090117221800.1387857041@smtp.haun-online.de>
Message-ID: <20090531170206.1671038898@smtp.haun-online.de>

Dirk Haun wrote (back in January):

>As can be seen from the recent commits, we have a small problem with
>line endings. All our files files have Unix line endings (linefeeds). So
>can our Windows users please try to make sure they *don't* change the
>line endings (to carriage return + linefeed) when checking things in?

There's actually a simple way to make Mercurial reject commits that
contain the wrong line endings:

[hooks]
pretxncommit.crlf = python:hgext.win32text.forbidcrlf

Add this to your .hgrc or mercurial.ini. If you then try to commit a
file with the "wrong" line endings, you'll get:

transaction abort!
rollback completed
abort: pretxncommit.crlf hook failed

Also see <http://wiki.geeklog.net/index.php/
Using_Mercurial#Windows_vs._Unix_Line_Endings>

bye, Dirk


-- 
http://www.geeklog.net/
http://geeklog.info/