[G3/Pg] Some news

[Romain LE DISEZ-5]

Hello all,

I was very busy for the last two weeks but today I found time to update
my patches for PgSQL. I post here for those who is interrested.

The tarball contains :
 - install.pg.sh :
      a shell script to install Gallery3 on PgSQL

 - install.pg.sql :
      an SQL script for installation on PgSQL

 - install.pg.d :
      a set of patches and a shell script to patch the code

Details about patches :
 - they are based on the last git code
 - theses patches are candidates for being push in trunk :
   (ask me if you need precisions)
    - 01-sql_boolean.patch
    - 02-sql_case_insensitive.patch
    - 03-sql_limit_offset.patch
    - 04-sql_useless_orderby.patch
    - 05-sql_comment-state_varchar.patch
 - theses patches are specific to PgSQL :
    - 50-remove_pg_schemaname.patch
    - 51-sql_fulltext_search.patch
 - and about 98-sql_left_right.patch and 99-remove-backquotes.sh,
   well... You know what it is ;-)

Notes :
 - the installation shell script probably only works on RedHat 5 but it
   is really short so you could easily fix it for your system. Edit the
   variables at the beggining and run it as root.

 - Currently, only a "basic" installation works. You can't
   install/uninstall modules because they have their owns SQL scripts
   and I hadn't yet look at them.

If you test it, please tell me if you found bugs that are not in the
official release.

Greetings.


------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bharat Mediratta]

Hi, Romain.  This looks interesting.  Are you maintaining these changes
in a fork on GitHub?  If you do that, then we can very easily pull in
the changes that you make which we want in the core code, and anybody
who wants to use Gallery 3 on Postgres can just follow your fork.
Keeping your fork in sync is very easy (no harder than what you're doing
today) but the sharing aspect is *much* easier.

-Bharat

Romain LE DISEZ wrote:

> Hello all,
>
> I was very busy for the last two weeks but today I found time to update
> my patches for PgSQL. I post here for those who is interrested.
>
> The tarball contains :
>  - install.pg.sh :
>       a shell script to install Gallery3 on PgSQL
>
>  - install.pg.sql :
>       an SQL script for installation on PgSQL
>
>  - install.pg.d :
>       a set of patches and a shell script to patch the code
>
> Details about patches :
>  - they are based on the last git code
>  - theses patches are candidates for being push in trunk :
>    (ask me if you need precisions)
>     - 01-sql_boolean.patch
>     - 02-sql_case_insensitive.patch
>     - 03-sql_limit_offset.patch
>     - 04-sql_useless_orderby.patch
>     - 05-sql_comment-state_varchar.patch
>  - theses patches are specific to PgSQL :
>     - 50-remove_pg_schemaname.patch
>     - 51-sql_fulltext_search.patch
>  - and about 98-sql_left_right.patch and 99-remove-backquotes.sh,
>    well... You know what it is ;-)
>
> Notes :
>  - the installation shell script probably only works on RedHat 5 but it
>    is really short so you could easily fix it for your system. Edit the
>    variables at the beggining and run it as root.
>
>  - Currently, only a "basic" installation works. You can't
>    install/uninstall modules because they have their owns SQL scripts
>    and I hadn't yet look at them.
>
> If you test it, please tell me if you found bugs that are not in the
> official release.
>
> Greetings.
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
>
>
> ------------------------------------------------------------------------
>
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Romain LE DISEZ-5]

Hi Bharat,

currently, I'm not maintaining a fork. I work directly on the code  
that I pull.

I may be wrong (I'm not used to git), but I believe it will be harder  
to maintain a fork than a set of patches. As I said in a previous  
mail, the problem of the backquotes is really blocking for me.  
Everytime I will want to merge the fork with the official code, I will  
have to check every SQL query because of the backquotes.

So, for now and with my knowledge of git, I'm not interrested in  
maintaining a fork. If you had choosed to remove the backquotes from  
the code, I would have done it.

But if you think that my understanding of git is wrong, just tell me.  
I'm always happy to learn something new.

Greetings.

Le 19 juin 09 à 22:09, Bharat Mediratta a écrit :

> Hi, Romain.  This looks interesting.  Are you maintaining these  
> changes
> in a fork on GitHub?  If you do that, then we can very easily pull in
> the changes that you make which we want in the core code, and anybody
> who wants to use Gallery 3 on Postgres can just follow your fork.
> Keeping your fork in sync is very easy (no harder than what you're  
> doing
> today) but the sharing aspect is *much* easier.
>
> -Bharat

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Donald Webster]

I can't claim to be a git expert, but I think you are using your svn
experience to make this assumption.  I'm pretty sure that with git,
maintaining your fork will be easier than maintaining a set of patches
(hard to believe!) because the git fork is still related in some way
to the parent.  You are able to pull down parent changes, resolving
conflicts where required and the opposite is also true.  The parent is
able to pull in your changes much more easily.

That said, I don't know how to do any of it... I have just talked to
bharat about git during our drives to the colo.

Everyone I know that has moved to git has been happy for it, it beats
all the others quite handily.  From what I know, there is already one
git fork of gallery3, maybe hunting that down could help explain
things (or give you someone to talk to that has done it).  I also
think bharat has git forked to work on portions of gallery3.

Anyway :)

AIM: fryfrog
WWW: http://www.fryfrog.com



On Fri, Jun 19, 2009 at 1:43 PM, Romain LE DISEZ<romain.g3@...> wrote:

> Hi Bharat,
>
> currently, I'm not maintaining a fork. I work directly on the code
> that I pull.
>
> I may be wrong (I'm not used to git), but I believe it will be harder
> to maintain a fork than a set of patches. As I said in a previous
> mail, the problem of the backquotes is really blocking for me.
> Everytime I will want to merge the fork with the official code, I will
> have to check every SQL query because of the backquotes.
>
> So, for now and with my knowledge of git, I'm not interrested in
> maintaining a fork. If you had choosed to remove the backquotes from
> the code, I would have done it.
>
> But if you think that my understanding of git is wrong, just tell me.
> I'm always happy to learn something new.
>
> Greetings.
>
> Le 19 juin 09 à 22:09, Bharat Mediratta a écrit :
>> Hi, Romain.  This looks interesting.  Are you maintaining these
>> changes
>> in a fork on GitHub?  If you do that, then we can very easily pull in
>> the changes that you make which we want in the core code, and anybody
>> who wants to use Gallery 3 on Postgres can just follow your fork.
>> Keeping your fork in sync is very easy (no harder than what you're
>> doing
>> today) but the sharing aspect is *much* easier.
>>
>> -Bharat
>
>
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]
>

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bharat Mediratta]

Romain LE DISEZ wrote:

> currently, I'm not maintaining a fork. I work directly on the code that
> I pull.
>
> I may be wrong (I'm not used to git), but I believe it will be harder to
> maintain a fork than a set of patches. As I said in a previous mail, the
> problem of the backquotes is really blocking for me. Everytime I will
> want to merge the fork with the official code, I will have to check
> every SQL query because of the backquotes.
>
> So, for now and with my knowledge of git, I'm not interrested in
> maintaining a fork. If you had choosed to remove the backquotes from the
> code, I would have done it.
>
> But if you think that my understanding of git is wrong, just tell me.
> I'm always happy to learn something new.

As Donald says, most people who have switched to Git have been pretty
happy with it.  But it depends on your workflow.  Git works well in the
case where you make changes to your copy and then commit them.  Then
when we make upstream changes, you just pull them in and they get
automatically merged.  It sounds like perhaps in your case you're
instead maintaining a series of patches and re-applying them after every
merge.  This may be harder for you in some cases (eg, if you have a
script to apply the backquotes) but it should be easier in many other
cases like when we do substantial refactors of the code and your patches
no longer apply cleanly.

My guess is that overall it would probably be easier for you, and
definitely easier for us to pull your changes back, if you use Git.  It
would require you to modify your backquotes script to be idempotent, but
it would also mean that we can easily see what you have in your fork and
decide to pull that into the main repository.  If you group your commits
aronud conceptual changes, we can cherrypick the ones that we want and
git will merge the two.

Either way, I'm pleased to see you continuing to push forward on Postges
and am curious to see where it leads.

-Bharat

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Alec Myers]

Bharat,

What was the reason for not removing back-quotes? Is this an issue that is
going to break (or require a patch/rewrite/fork of) every contributed module
too because G3 syntax requires backquotes, but they need to be removed to
work with PgSQL?

I've not followed the technicalities in great depth, but if that is the
case, now might be a good time to look at the backquotes issue again before
there are lots of contrib modules to fix too?

I do understand and agree with not explicitly *supporting* db's other than
MySQL, but I can see an argument for not making it harder than it needs to
be, either. What's the downside of changing this as far as core MySQL
support is concerned that makes it a worthwhile penalty?



-Alec


----- Original Message -----
From: "Bharat Mediratta" <bharat@...>
To: "Romain LE DISEZ" <romain.g3@...>
Cc: "Gallery Community" <gallery-devel@...>
Sent: Saturday, June 20, 2009 12:02 AM
Subject: Re: [Gallery-devel] [G3/Pg] Some news


Romain LE DISEZ wrote:

> currently, I'm not maintaining a fork. I work directly on the code that
> I pull.
>
> I may be wrong (I'm not used to git), but I believe it will be harder to
> maintain a fork than a set of patches. As I said in a previous mail, the
> problem of the backquotes is really blocking for me. Everytime I will
> want to merge the fork with the official code, I will have to check
> every SQL query because of the backquotes.
>
> So, for now and with my knowledge of git, I'm not interrested in
> maintaining a fork. If you had choosed to remove the backquotes from the
> code, I would have done it.
>
> But if you think that my understanding of git is wrong, just tell me.
> I'm always happy to learn something new.

As Donald says, most people who have switched to Git have been pretty
happy with it.  But it depends on your workflow.  Git works well in the
case where you make changes to your copy and then commit them.  Then
when we make upstream changes, you just pull them in and they get
automatically merged.  It sounds like perhaps in your case you're
instead maintaining a series of patches and re-applying them after every
merge.  This may be harder for you in some cases (eg, if you have a
script to apply the backquotes) but it should be easier in many other
cases like when we do substantial refactors of the code and your patches
no longer apply cleanly.

My guess is that overall it would probably be easier for you, and
definitely easier for us to pull your changes back, if you use Git.  It
would require you to modify your backquotes script to be idempotent, but
it would also mean that we can easily see what you have in your fork and
decide to pull that into the main repository.  If you group your commits
aronud conceptual changes, we can cherrypick the ones that we want and
git will merge the two.

Either way, I'm pleased to see you continuing to push forward on Postges
and am curious to see where it leads.

-Bharat

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge
conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference:
$250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]



------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Andy Staudacher-3]

On Fri, Jun 19, 2009 at 4:14 PM, Alec Myers <alec@...> wrote:

Bharat,

What was the reason for not removing back-quotes?

[...in SQL]

Use of reserved words in SQL. Gallery 3 uses a couple of reserved words of the MySQL vocabulary.

Specifically we use "key", "left" and "right" as column names. If you want to do that, you need to escape the column names with backticks in MySQL.

Other RDBMS have different escaping mechanisms.

Currently, the issue has been assigned to me. And I say: let's get rid of reserved MySQL words, and thus let's do away with backticks.

The beta 1 > beta 2 upgrade will have to rename a few columns. Which is ugly, but that's what we'll have to do.

This issue is blocked until we've figured out how to do (DB) upgrades. Which is on the roadmap for beta 2 anyway.

 - Andy

 

Is this an issue that is
going to break (or require a patch/rewrite/fork of) every contributed module
too because G3 syntax requires backquotes, but they need to be removed to
work with PgSQL?

I've not followed the technicalities in great depth, but if that is the
case, now might be a good time to look at the backquotes issue again before
there are lots of contrib modules to fix too?

I do understand and agree with not explicitly *supporting* db's other than
MySQL, but I can see an argument for not making it harder than it needs to
be, either. What's the downside of changing this as far as core MySQL
support is concerned that makes it a worthwhile penalty?



-Alec

----- Original Message -----
From: "Bharat Mediratta" <bharat@...>
To: "Romain LE DISEZ" <romain.g3@...>
Cc: "Gallery Community" <gallery-devel@...>
Sent: Saturday, June 20, 2009 12:02 AM
Subject: Re: [Gallery-devel] [G3/Pg] Some news


Romain LE DISEZ wrote:
> currently, I'm not maintaining a fork. I work directly on the code that
> I pull.
>
> I may be wrong (I'm not used to git), but I believe it will be harder to
> maintain a fork than a set of patches. As I said in a previous mail, the
> problem of the backquotes is really blocking for me. Everytime I will
> want to merge the fork with the official code, I will have to check
> every SQL query because of the backquotes.
>
> So, for now and with my knowledge of git, I'm not interrested in
> maintaining a fork. If you had choosed to remove the backquotes from the
> code, I would have done it.
>
> But if you think that my understanding of git is wrong, just tell me.
> I'm always happy to learn something new.

As Donald says, most people who have switched to Git have been pretty
happy with it.  But it depends on your workflow.  Git works well in the
case where you make changes to your copy and then commit them.  Then
when we make upstream changes, you just pull them in and they get
automatically merged.  It sounds like perhaps in your case you're
instead maintaining a series of patches and re-applying them after every
merge.  This may be harder for you in some cases (eg, if you have a
script to apply the backquotes) but it should be easier in many other
cases like when we do substantial refactors of the code and your patches
no longer apply cleanly.

My guess is that overall it would probably be easier for you, and
definitely easier for us to pull your changes back, if you use Git.  It
would require you to modify your backquotes script to be idempotent, but
it would also mean that we can easily see what you have in your fork and
decide to pull that into the main repository.  If you group your commits
aronud conceptual changes, we can cherrypick the ones that we want and
git will merge the two.

Either way, I'm pleased to see you continuing to push forward on Postges
and am curious to see where it leads.

-Bharat

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge
conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference:
$250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]



------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Romain LE DISEZ-5]

Backquotes are not the problem, they are a consequence. Backquotes are  
needed because some columns names of the DB use reserved keywords :  
items.left, items.right and *_translations.key  (left, right and key  
are reserved in SQL).

To summarize the discussion we had: I was suggesting to rename those  
columns to left_bound and right_bound, Bharat objected that left and  
right make more sense so he was not going to rename them.

Greetings.

Le 20 juin 09 à 01:14, Alec Myers a écrit :

> Bharat,
>
> What was the reason for not removing back-quotes? Is this an issue  
> that is
> going to break (or require a patch/rewrite/fork of) every  
> contributed module
> too because G3 syntax requires backquotes, but they need to be  
> removed to
> work with PgSQL?
>
> I've not followed the technicalities in great depth, but if that is  
> the
> case, now might be a good time to look at the backquotes issue again  
> before
> there are lots of contrib modules to fix too?
>
> I do understand and agree with not explicitly *supporting* db's  
> other than
> MySQL, but I can see an argument for not making it harder than it  
> needs to
> be, either. What's the downside of changing this as far as core MySQL
> support is concerned that makes it a worthwhile penalty?
>
>
>
> -Alec
>
>
> ----- Original Message -----
> From: "Bharat Mediratta" <bharat@...>
> To: "Romain LE DISEZ" <romain.g3@...>
> Cc: "Gallery Community" <gallery-devel@...>
> Sent: Saturday, June 20, 2009 12:02 AM
> Subject: Re: [Gallery-devel] [G3/Pg] Some news
>
>
> Romain LE DISEZ wrote:
>> currently, I'm not maintaining a fork. I work directly on the code  
>> that
>> I pull.
>>
>> I may be wrong (I'm not used to git), but I believe it will be  
>> harder to
>> maintain a fork than a set of patches. As I said in a previous  
>> mail, the
>> problem of the backquotes is really blocking for me. Everytime I will
>> want to merge the fork with the official code, I will have to check
>> every SQL query because of the backquotes.
>>
>> So, for now and with my knowledge of git, I'm not interrested in
>> maintaining a fork. If you had choosed to remove the backquotes  
>> from the
>> code, I would have done it.
>>
>> But if you think that my understanding of git is wrong, just tell me.
>> I'm always happy to learn something new.
>
> As Donald says, most people who have switched to Git have been pretty
> happy with it.  But it depends on your workflow.  Git works well in  
> the
> case where you make changes to your copy and then commit them.  Then
> when we make upstream changes, you just pull them in and they get
> automatically merged.  It sounds like perhaps in your case you're
> instead maintaining a series of patches and re-applying them after  
> every
> merge.  This may be harder for you in some cases (eg, if you have a
> script to apply the backquotes) but it should be easier in many other
> cases like when we do substantial refactors of the code and your  
> patches
> no longer apply cleanly.
>
> My guess is that overall it would probably be easier for you, and
> definitely easier for us to pull your changes back, if you use Git.  
> It
> would require you to modify your backquotes script to be idempotent,  
> but
> it would also mean that we can easily see what you have in your fork  
> and
> decide to pull that into the main repository.  If you group your  
> commits
> aronud conceptual changes, we can cherrypick the ones that we want and
> git will merge the two.
>
> Either way, I'm pleased to see you continuing to push forward on  
> Postges
> and am curious to see where it leads.
>
> -Bharat
>
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge
> conference!
> Portland, OR, June 17-19. Two days of sessions, one day of  
> unconference:
> $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]
>
>
>
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge  
> conference!
> Portland, OR, June 17-19. Two days of sessions, one day of  
> unconference: $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]

--
Romain LE DISEZ
06.78.77.99.18
http://www.ledisez.net/




--
Romain LE DISEZ
06.78.77.99.18
http://www.ledisez.net/





------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Andy Staudacher-3]

Resending. For some reason it doesn't show up in the list archives.

On Fri, Jun 19, 2009 at 5:55 PM, Andy Staudacher <[e-mail]> wrote:

On Fri, Jun 19, 2009 at 4:14 PM, Alec Myers <alec@...> wrote:

Bharat,

What was the reason for not removing back-quotes?

[...in SQL]

Use of reserved words in SQL. Gallery 3 uses a couple of reserved words of the MySQL vocabulary.

Specifically we use "key", "left" and "right" as column names. If you want to do that, you need to escape the column names with backticks in MySQL.

Other RDBMS have different escaping mechanisms.

Currently, the issue has been assigned to me. And I say: let's get rid of reserved MySQL words, and thus let's do away with backticks.

The beta 1 > beta 2 upgrade will have to rename a few columns. Which is ugly, but that's what we'll have to do.

This issue is blocked until we've figured out how to do (DB) upgrades. Which is on the roadmap for beta 2 anyway.

 - Andy

 

Is this an issue that is
going to break (or require a patch/rewrite/fork of) every contributed module
too because G3 syntax requires backquotes, but they need to be removed to
work with PgSQL?

I've not followed the technicalities in great depth, but if that is the
case, now might be a good time to look at the backquotes issue again before
there are lots of contrib modules to fix too?

I do understand and agree with not explicitly *supporting* db's other than
MySQL, but I can see an argument for not making it harder than it needs to
be, either. What's the downside of changing this as far as core MySQL
support is concerned that makes it a worthwhile penalty?



-Alec

----- Original Message -----
From: "Bharat Mediratta" <bharat@...>
To: "Romain LE DISEZ" <romain.g3@...>
Cc: "Gallery Community" <gallery-devel@...>
Sent: Saturday, June 20, 2009 12:02 AM
Subject: Re: [Gallery-devel] [G3/Pg] Some news


Romain LE DISEZ wrote:
> currently, I'm not maintaining a fork. I work directly on the code that
> I pull.
>
> I may be wrong (I'm not used to git), but I believe it will be harder to
> maintain a fork than a set of patches. As I said in a previous mail, the
> problem of the backquotes is really blocking for me. Everytime I will
> want to merge the fork with the official code, I will have to check
> every SQL query because of the backquotes.
>
> So, for now and with my knowledge of git, I'm not interrested in
> maintaining a fork. If you had choosed to remove the backquotes from the
> code, I would have done it.
>
> But if you think that my understanding of git is wrong, just tell me.
> I'm always happy to learn something new.

As Donald says, most people who have switched to Git have been pretty
happy with it.  But it depends on your workflow.  Git works well in the
case where you make changes to your copy and then commit them.  Then
when we make upstream changes, you just pull them in and they get
automatically merged.  It sounds like perhaps in your case you're
instead maintaining a series of patches and re-applying them after every
merge.  This may be harder for you in some cases (eg, if you have a
script to apply the backquotes) but it should be easier in many other
cases like when we do substantial refactors of the code and your patches
no longer apply cleanly.

My guess is that overall it would probably be easier for you, and
definitely easier for us to pull your changes back, if you use Git.  It
would require you to modify your backquotes script to be idempotent, but
it would also mean that we can easily see what you have in your fork and
decide to pull that into the main repository.  If you group your commits
aronud conceptual changes, we can cherrypick the ones that we want and
git will merge the two.

Either way, I'm pleased to see you continuing to push forward on Postges
and am curious to see where it leads.

-Bharat

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge
conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference:
$250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]



------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bharat Mediratta]

It's not as trivial as renaming a few columns.  I spent about 30 minutes
on this and here's what's involved:

1) Getting rid of backticks (as Romain points out, this is a
consequence, but they still have to get removed for portability)

2) Rename the following columns (at least):
      $db->query("ALTER TABLE {items} CHANGE `left` left_ptr int(9) NOT
NULL");
      $db->query("ALTER TABLE {items} CHANGE `right` right_ptr int(9)
NOT NULL");
      $db->query("ALTER TABLE {vars} CHANGE `value` data text");

(missing the key columns from the *_translations tables)

3) Update all uses of left, right, key, value, etc to match.  This is a
pain, but it's doable and our tests probably cover us here.

So far so good.  I did all of the above.  We have installer code that
can deal with the column renaming, etc.  But the next hurdle is that the
upgrader runs as a controller, and we load the vars table before we run
controllers, and we're changing out one of the column names in the vars
table (from "value" to "data") which causes the precaching of the vars
table to fail.  Can't load vars, can't get anything off the ground.

Can we work around this?  Yes.  But honestly, I'm just not willing to
put any more time into this.  MySQL is plenty for me, and for enough of
our userbase that I'm not willing to prioritize it above any of the
other 100+ tickets we have open for beta 2 currently.

-Bharat

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Romain LE DISEZ-5]

Hey ! I wasn't aware of that. As you could guess, I will be happy to
help you.

Is there a ticket (I looked on Trac but I hadn'd found) or a branch I
can pull ?

Greetings.

Le samedi 20 juin 2009 à 00:55 -0700, Andy Staudacher a écrit :

>         Currently, the issue has been assigned to me. And I say: let's
>         get rid of reserved MySQL words, and thus let's do away with
>         backticks.
>        
>        
>         The beta 1 > beta 2 upgrade will have to rename a few columns.
>         Which is ugly, but that's what we'll have to do.
>        
>        
>         This issue is blocked until we've figured out how to do (DB)
>         upgrades. Which is on the roadmap for beta 2 anyway.

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Andy Staudacher-3]

Resending again...

@Bharat:

Any idea why my mail isn't getting through?

(I keep forgetting the new list pw)

Thanks,

 - Andy

On Sat, Jun 20, 2009 at 12:55 AM, Andy Staudacher <[e-mail]> wrote:

Resending. For some reason it doesn't show up in the list archives.

On Fri, Jun 19, 2009 at 5:55 PM, Andy Staudacher <[e-mail]> wrote:

On Fri, Jun 19, 2009 at 4:14 PM, Alec Myers <alec@...> wrote:

Bharat,

What was the reason for not removing back-quotes?

[...in SQL]

Use of reserved words in SQL. Gallery 3 uses a couple of reserved words of the MySQL vocabulary.

Specifically we use "key", "left" and "right" as column names. If you want to do that, you need to escape the column names with backticks in MySQL.

Other RDBMS have different escaping mechanisms.

Currently, the issue has been assigned to me. And I say: let's get rid of reserved MySQL words, and thus let's do away with backticks.

The beta 1 > beta 2 upgrade will have to rename a few columns. Which is ugly, but that's what we'll have to do.

This issue is blocked until we've figured out how to do (DB) upgrades. Which is on the roadmap for beta 2 anyway.

 - Andy

 

Is this an issue that is
going to break (or require a patch/rewrite/fork of) every contributed module
too because G3 syntax requires backquotes, but they need to be removed to
work with PgSQL?

I've not followed the technicalities in great depth, but if that is the
case, now might be a good time to look at the backquotes issue again before
there are lots of contrib modules to fix too?

I do understand and agree with not explicitly *supporting* db's other than
MySQL, but I can see an argument for not making it harder than it needs to
be, either. What's the downside of changing this as far as core MySQL
support is concerned that makes it a worthwhile penalty?



-Alec

----- Original Message -----
From: "Bharat Mediratta" <bharat@...>
To: "Romain LE DISEZ" <romain.g3@...>
Cc: "Gallery Community" <gallery-devel@...>
Sent: Saturday, June 20, 2009 12:02 AM
Subject: Re: [Gallery-devel] [G3/Pg] Some news


Romain LE DISEZ wrote:
> currently, I'm not maintaining a fork. I work directly on the code that
> I pull.
>
> I may be wrong (I'm not used to git), but I believe it will be harder to
> maintain a fork than a set of patches. As I said in a previous mail, the
> problem of the backquotes is really blocking for me. Everytime I will
> want to merge the fork with the official code, I will have to check
> every SQL query because of the backquotes.
>
> So, for now and with my knowledge of git, I'm not interrested in
> maintaining a fork. If you had choosed to remove the backquotes from the
> code, I would have done it.
>
> But if you think that my understanding of git is wrong, just tell me.
> I'm always happy to learn something new.

As Donald says, most people who have switched to Git have been pretty
happy with it.  But it depends on your workflow.  Git works well in the
case where you make changes to your copy and then commit them.  Then
when we make upstream changes, you just pull them in and they get
automatically merged.  It sounds like perhaps in your case you're
instead maintaining a series of patches and re-applying them after every
merge.  This may be harder for you in some cases (eg, if you have a
script to apply the backquotes) but it should be easier in many other
cases like when we do substantial refactors of the code and your patches
no longer apply cleanly.

My guess is that overall it would probably be easier for you, and
definitely easier for us to pull your changes back, if you use Git.  It
would require you to modify your backquotes script to be idempotent, but
it would also mean that we can easily see what you have in your fork and
decide to pull that into the main repository.  If you group your commits
aronud conceptual changes, we can cherrypick the ones that we want and
git will merge the two.

Either way, I'm pleased to see you continuing to push forward on Postges
and am curious to see where it leads.

-Bharat

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge
conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference:
$250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]



------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Andy Staudacher-3]

Resending my reply from yesterday. For some reason it never made it through.

On Fri, Jun 19, 2009 at 4:14 PM, Alec Myers <alec@...> wrote:

Bharat,

What was the reason for not removing back-quotes?

[...in SQL]

Use of reserved words in SQL. Gallery 3 uses a couple of reserved words of the MySQL vocabulary.

Specifically we use "key", "left" and "right" as column names. If you want to do that, you need to escape the column names with backticks in MySQL.

Other RDBMS have different escaping mechanisms.

Currently, the issue has been assigned to me. And I say: let's get rid of reserved MySQL words, and thus let's do away with backticks.

The beta 1 > beta 2 upgrade will have to rename a few columns. Which is ugly, but that's what we'll have to do.

This issue is blocked until we've figured out how to do (DB) upgrades. Which is on the roadmap for beta 2 anyway.

 - Andy

On Fri, Jun 19, 2009 at 4:14 PM, Alec Myers <alec@...> wrote:

Bharat,

What was the reason for not removing back-quotes? Is this an issue that is
going to break (or require a patch/rewrite/fork of) every contributed module
too because G3 syntax requires backquotes, but they need to be removed to
work with PgSQL?

I've not followed the technicalities in great depth, but if that is the
case, now might be a good time to look at the backquotes issue again before
there are lots of contrib modules to fix too?

I do understand and agree with not explicitly *supporting* db's other than
MySQL, but I can see an argument for not making it harder than it needs to
be, either. What's the downside of changing this as far as core MySQL
support is concerned that makes it a worthwhile penalty?



-Alec

----- Original Message -----
From: "Bharat Mediratta" <bharat@...>
To: "Romain LE DISEZ" <romain.g3@...>
Cc: "Gallery Community" <gallery-devel@...>
Sent: Saturday, June 20, 2009 12:02 AM
Subject: Re: [Gallery-devel] [G3/Pg] Some news


Romain LE DISEZ wrote:
> currently, I'm not maintaining a fork. I work directly on the code that
> I pull.
>
> I may be wrong (I'm not used to git), but I believe it will be harder to
> maintain a fork than a set of patches. As I said in a previous mail, the
> problem of the backquotes is really blocking for me. Everytime I will
> want to merge the fork with the official code, I will have to check
> every SQL query because of the backquotes.
>
> So, for now and with my knowledge of git, I'm not interrested in
> maintaining a fork. If you had choosed to remove the backquotes from the
> code, I would have done it.
>
> But if you think that my understanding of git is wrong, just tell me.
> I'm always happy to learn something new.

As Donald says, most people who have switched to Git have been pretty
happy with it.  But it depends on your workflow.  Git works well in the
case where you make changes to your copy and then commit them.  Then
when we make upstream changes, you just pull them in and they get
automatically merged.  It sounds like perhaps in your case you're
instead maintaining a series of patches and re-applying them after every
merge.  This may be harder for you in some cases (eg, if you have a
script to apply the backquotes) but it should be easier in many other
cases like when we do substantial refactors of the code and your patches
no longer apply cleanly.

My guess is that overall it would probably be easier for you, and
definitely easier for us to pull your changes back, if you use Git.  It
would require you to modify your backquotes script to be idempotent, but
it would also mean that we can easily see what you have in your fork and
decide to pull that into the main repository.  If you group your commits
aronud conceptual changes, we can cherrypick the ones that we want and
git will merge the two.

Either way, I'm pleased to see you continuing to push forward on Postges
and am curious to see where it leads.

-Bharat

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge
conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference:
$250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]



------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Romain LE DISEZ-5]

Hi all,

Le vendredi 19 juin 2009 à 13:09 -0700, Bharat Mediratta a écrit :
> Are you maintaining these changes
> in a fork on GitHub?  If you do that, then we can very easily pull in
> the changes that you make which we want in the core code, and anybody
> who wants to use Gallery 3 on Postgres can just follow your fork.

I found a way to work with fork. I forked gallery3 [1]. In this fork, I
will only apply modifications that are candidates for inclusion in the
official tree.

I think in the near futur I will fork my fork, to put modifications that
are specific to PgSQL.

(I probably reinvented the wheel, but I'm not used to git...)


> Keeping your fork in sync is very easy (no harder than what you're doing
> today) but the sharing aspect is *much* easier.

Yes, you're probably right, it looks easy. I'm waiting modifications in
the official tree, to test the merge function.


Now a question : how will you know that there are modifications in my
fork ? Will you look it regularly or should I tell you when I think my
modifications can be merged ?

Greetings.

[1] http://github.com/rledisez/gallery3/tree/master


------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Tim Almdal]

Romain:
On Github on the project page, there is a "Fork Queue" tab.  This will tell you all the modifications that have been made to all the forks.  You can just "cherry pick" the ones you want to apply.

----- Original Message -----
From: Romain LE DISEZ <romain.g3@...>
Date: Tuesday, June 23, 2009 1:39 am
Subject: Re: [Gallery-devel] [G3/Pg] Some news
To: Bharat Mediratta <bharat@...>
Cc: Gallery Community <gallery-devel@...>

> Hi all,
>
> Le vendredi 19 juin 2009 à 13:09 -0700, Bharat Mediratta a écrit :
> > Are you maintaining these changes
> > in a fork on GitHub?  If you do that, then we can very
> easily pull in
> > the changes that you make which we want in the core code, and
> anybody> who wants to use Gallery 3 on Postgres can just follow
> your fork.
>
> I found a way to work with fork. I forked gallery3 [1]. In this
> fork, I
> will only apply modifications that are candidates for inclusion
> in the
> official tree.
>
> I think in the near futur I will fork my fork, to put
> modifications that
> are specific to PgSQL.
>
> (I probably reinvented the wheel, but I'm not used to git...)
>
>
> > Keeping your fork in sync is very easy (no harder than what
> you're doing
> > today) but the sharing aspect is *much* easier.
>
> Yes, you're probably right, it looks easy. I'm waiting
> modifications in
> the official tree, to test the merge function.
>
>
> Now a question : how will you know that there are modifications
> in my
> fork ? Will you look it regularly or should I tell you when I
> think my
> modifications can be merged ?
>
> Greetings.
>
> [1] http://github.com/rledisez/gallery3/tree/master
>
>
> -----------------------------------------------------------------
> -------------
> Are you an open source citizen? Join us for the Open Source
> Bridge conference!
> Portland, OR, June 17-19. Two days of sessions, one day of
> unconference: $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]

Website: http://www.timalmdal.com


------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Romain LE DISEZ-5]

Le mardi 23 juin 2009 à 04:54 -0700, Tim Almdal a écrit :
> Romain:
> On Github on the project page, there is a "Fork Queue" tab.  This will
> tell you all the modifications that have been made to all the forks.
> You can just "cherry pick" the ones you want to apply.

Cool! So, core developpers can follow the forks.

There is also the "Pull request", if they forget about me... :-)



------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bharat Mediratta]

Romain LE DISEZ wrote:
> Le mardi 23 juin 2009 à 04:54 -0700, Tim Almdal a écrit :
>> Romain:
>> On Github on the project page, there is a "Fork Queue" tab.  This will
>> tell you all the modifications that have been made to all the forks.
>> You can just "cherry pick" the ones you want to apply.
>
> Cool! So, core developpers can follow the forks.
>
> There is also the "Pull request", if they forget about me... :-)

I check all forks periodically.  Github makes this fairly easy.

I've pulled these two changes in:
  da0918   SQL is case insensitive
  297ac6   Improve compatibility with other RDBMS

This one I had to hand tweak.
  d601ab  Value stored in comment.state is not 15 char le...
Now that we're in betas, we have to provide an upgrade path so just
changing the SQL isn't enough.  I created an upgrade path for it in the
comment module.

This one I couldn't accept:
  c80d2d  Remove an useless ORDER BY.
Your change is correct, except that there's a bug in that code that
required me to significantly restructure it.  When you next pull you'll
probably want to overwrite your changes with mine, then get the new
stuff working with Postrgres.

This one I had questions about:
  de28b0  Use an integer because the code store 0 and 1. It
If I understand correctly, you're saying that it's ok to use BOOLEAN if
we use TRUE/FALSE instead of 1/0 everywhere in the code?  Wouldn't it be
the responsibility of the Postgres driver to do that conversion for us?

Thanks for contributing!  For reference, your changes go into our
codebase with your name on them, eg:

http://github.com/gallery/gallery3/commit/da09185a4baa739dd011804eb1301cdf2d126c11


-Bharat

------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Romain LE DISEZ-5]

Le mardi 23 juin 2009 à 15:26 -0700, Bharat Mediratta a écrit :
> This one I couldn't accept:
>   c80d2d  Remove an useless ORDER BY.
> Your change is correct, except that there's a bug in that code that
> required me to significantly restructure it.  When you next pull you'll
> probably want to overwrite your changes with mine, then get the new
> stuff working with Postrgres.

OK. Done.

>
> This one I had questions about:
>   de28b0  Use an integer because the code store 0 and 1. It
> If I understand correctly, you're saying that it's ok to use BOOLEAN if
> we use TRUE/FALSE instead of 1/0 everywhere in the code?  Wouldn't it be
> the responsibility of the Postgres driver to do that conversion for us?

Yes, I agree with you that the driver should test the type of the field
manipulated.

But the Kohanna developpers seems to have made an other choice. I looked
at the code [1] that constructs SQL query : it just passes the values
without any check. Only the fields names are escaped, the values aren't
touched.

I will not provide a patch to Kohanna about that. It will not be
accepted because it will probably break a lot of applications. The other
solution is to overload all those functions in
modules/gallery/libraries/MY_Database.php. But it's just doing the job
of the framework, so I don't think it's the good solution.

My patch is the simplest way. But I can work on correcting the code with
real boolean values, it will be a big patch.

[1] system/libraries/drivers/Database.php : look for function insert(),
update(), ...

Greetings.


------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bharat Mediratta]

Romain LE DISEZ wrote:

>> This one I had questions about:
>>   de28b0  Use an integer because the code store 0 and 1. It
>> If I understand correctly, you're saying that it's ok to use BOOLEAN if
>> we use TRUE/FALSE instead of 1/0 everywhere in the code?  Wouldn't it be
>> the responsibility of the Postgres driver to do that conversion for us?
>
> Yes, I agree with you that the driver should test the type of the field
> manipulated.
>
> But the Kohanna developpers seems to have made an other choice. I looked
> at the code [1] that constructs SQL query : it just passes the values
> without any check. Only the fields names are escaped, the values aren't
> touched.

...

Ok.  As I understand it, the Kohana folks are going to stop actively
supporting the Postgres database driver so pushing them to fix it might
be a rathole.

How about leaving the field as a BOOLEAN and fixing all the occurrences
of 1/0 to true/false?  Upon some reflection, I think that's a fair
change for us to make in Gallery3 because it makes it clear to us that
we're dealing with a bool.  This is a discipline that we should probably
have.  If that works for you, then make that change in your repo and
I'll pull it into Gallery3.

thanks,
-Bharat

------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Romain LE DISEZ-5]

Le mercredi 24 juin 2009 à 17:26 -0700, Bharat Mediratta a écrit :

> Romain LE DISEZ wrote:
> >> This one I had questions about:
> >>   de28b0  Use an integer because the code store 0 and 1. It
> >> If I understand correctly, you're saying that it's ok to use BOOLEAN if
> >> we use TRUE/FALSE instead of 1/0 everywhere in the code?  Wouldn't it be
> >> the responsibility of the Postgres driver to do that conversion for us?
> >
> > Yes, I agree with you that the driver should test the type of the field
> > manipulated.
> >
> > But the Kohanna developpers seems to have made an other choice. I looked
> > at the code [1] that constructs SQL query : it just passes the values
> > without any check. Only the fields names are escaped, the values aren't
> > touched.
> ...
>
> Ok.  As I understand it, the Kohana folks are going to stop actively
> supporting the Postgres database driver so pushing them to fix it might
> be a rathole.
>
> How about leaving the field as a BOOLEAN and fixing all the occurrences
> of 1/0 to true/false?  Upon some reflection, I think that's a fair
> change for us to make in Gallery3 because it makes it clear to us that
> we're dealing with a bool.  This is a discipline that we should probably
> have.  If that works for you, then make that change in your repo and
> I'll pull it into Gallery3.

I'm working on it. I finally found a place where Kohana convert a
boolean to an integer, it's very strange, I will propose a patch. This
way the diff for Gallery will be smallest and more coherent.

I'm leaving today for a two weeks trip so don't expect to see a commit
before three or four weeks.

Greetings.


------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]