Fwd: Getting rid of reserved SQL words

[Romain LE DISEZ-5]

(sorry for the double post, I posted with the wrong address)

Le 25 juil. 09 à 17:22, Romain LE DISEZ a écrit :

>> As for the column names that we should choose. Here are some
>> modifications to your proposal:
>>
>> * items.left                 -> lft, left_val, left_value, left_bound
>> * items.right                -> rgt, right_val, right_value,
>> right_bound
>
> I'm going to code that. I will use the proposition of Bharat :
> left_ptr and right_ptr. If it gets merged, I will code the rename of
> the columns "key" with your proposition (cache_key, msg_key and label)

I commited it with the upgrade code [1], it's a big diff. The units  
tests pass and my personals tests also. I ran it on a gallery of about  
30 albums and 1300 photos. I checked addition, deletion of photos and  
albums. After each operations I looked the values of left_ptr and  
right_ptr.

I'm waiting for your comments.

[1] http://github.com/rledisez/gallery3/commit/23bb6eb7e35637c8a2124216dbb6d3246ad3d702

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 ]

[Andy Staudacher-3]

Hi Romain,

Great work! I've reviewed the changes and it all looks good.

I've done some sanity checks (grep'ing, running tests). Looks like you've covered everything.

I've also verified that keywords like "count" or "timestamp" are indeed no problem in MySQL queries as column names. Makes for fun queries like select count(count). :)

I've merged your left / right -> left_ptr / right_ptr changes to the master tree.

The one thing I reverted was your change to install.sql which removed the charset settings. These would creep back in the next time we do a packaging anyway.

See:

http://github.com/gallery/gallery3/commit/482e223b602d60eec424081d0328cde66d28a758

Let's continue with these changes. Please let me know when the next batch of changes is ready. :)

Thanks,

 - Andy

On Sat, Jul 25, 2009 at 3:26 PM, Romain LE DISEZ <romain.g3@...> wrote:

(sorry for the double post, I posted with the wrong address)

Le 25 juil. 09 à 17:22, Romain LE DISEZ a écrit :
>> As for the column names that we should choose. Here are some
>> modifications to your proposal:
>>
>> * items.left                 -> lft, left_val, left_value, left_bound
>> * items.right                -> rgt, right_val, right_value,
>> right_bound
>
> I'm going to code that. I will use the proposition of Bharat :
> left_ptr and right_ptr. If it gets merged, I will code the rename of
> the columns "key" with your proposition (cache_key, msg_key and label)

I commited it with the upgrade code [1], it's a big diff. The units
tests pass and my personals tests also. I ran it on a gallery of about
30 albums and 1300 photos. I checked addition, deletion of photos and
albums. After each operations I looked the values of left_ptr and
right_ptr.

I'm waiting for your comments.

[1] http://github.com/rledisez/gallery3/commit/23bb6eb7e35637c8a2124216dbb6d3246ad3d702

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 ]

------------------------------------------------------------------------------

__[ 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 lundi 27 juillet 2009 à 00:26 -0700, Andy Staudacher a écrit :
> The one thing I reverted was your change to install.sql which removed
> the charset settings. These would creep back in the next time we do a
> packaging anyway.
> See:
> http://github.com/gallery/gallery3/commit/482e223b602d60eec424081d0328cde66d28a758

I was not sure about this change. I don't understand why charset
settings were removed because I used the command "php index.php
package". I'm running MySQL 5.0.45 on CentOS 5.3.


>
> Let's continue with these changes. Please let me know when the next
> batch of changes is ready. :)

I will work on them, trying to finish these modifications before next
beta.

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]

Andy, how did you integrate this change?  It seems like you pulled in
Romain's entire fork!  This is bad, he's got stuff in there that we
cannot have in our repo, like
http://github.com/gallery/gallery3/commit/c80d2da0a95a63b76f5a4c835f1a0e1022ec2f53
which breaks our sort orders.  I've been carefully cherrypicking his
changes to avoid this.  It also has the complete history of all the
other stuff that Romain tried that we also really don't want in our
history, eg:
http://github.com/gallery/gallery3/commit/923732ca4dca6db218f6252a7133cd72f98fa086
this isn't terrible, but it's really not what we want in our history.

Because of the way that git works, now that it's in our canonical repo
we're kind of screwed.  We can rebase the canonical repo and remove
those changes, but anybody who's done a pull has them, and if any of
*those* people push directly back, then they'll come back again.  The
only way to fix this is to rebase the canonical repo, then either we all
rebase our own repos or we delete them and re-clone and start again.
And that won't fix any non-dev out there who's got a repo who has done a
pull in the meantime (although at least they won't be able to push back
to us).

I'm willing to do this, but I think we'd have to turn off direct push
privileges and only turn them back on when developers assert that
they've cleaned out their repos.  And if anybody has an old repo out
there containing these changes and accidentally pushes in the future,
then we're screwed again.  :-(

I am not sure how much time I have to deal with this today.  Please make
it a priority to review each of the changes from that fork and remove
any of the ones that are not essential for the column rename.

-Bharat


Andy Staudacher wrote:

> Hi Romain,
>
> Great work! I've reviewed the changes and it all looks good.
>
> I've done some sanity checks (grep'ing, running tests). Looks like
> you've covered everything.
> I've also verified that keywords like "count" or "timestamp" are indeed
> no problem in MySQL queries as column names. Makes for fun queries like
> select count(count). :)
>
> I've merged your left / right -> left_ptr / right_ptr changes to the
> master tree.
>
> The one thing I reverted was your change to install.sql which removed
> the charset settings. These would creep back in the next time we do a
> packaging anyway.
> See:
> http://github.com/gallery/gallery3/commit/482e223b602d60eec424081d0328cde66d28a758
>
> Let's continue with these changes. Please let me know when the next
> batch of changes is ready. :)
>
> Thanks,
>  - Andy
>
> On Sat, Jul 25, 2009 at 3:26 PM, Romain LE DISEZ <romain.g3@...
> <mailto:romain.g3@...>> wrote:
>
>     (sorry for the double post, I posted with the wrong address)
>
>     Le 25 juil. 09 à 17:22, Romain LE DISEZ a écrit :
>     >> As for the column names that we should choose. Here are some
>     >> modifications to your proposal:
>     >>
>     >> * items.left                 -> lft, left_val, left_value, left_bound
>     >> * items.right                -> rgt, right_val, right_value,
>     >> right_bound
>     >
>     > I'm going to code that. I will use the proposition of Bharat :
>     > left_ptr and right_ptr. If it gets merged, I will code the rename of
>     > the columns "key" with your proposition (cache_key, msg_key and label)
>
>     I commited it with the upgrade code [1], it's a big diff. The units
>     tests pass and my personals tests also. I ran it on a gallery of about
>     30 albums and 1300 photos. I checked addition, deletion of photos and
>     albums. After each operations I looked the values of left_ptr and
>     right_ptr.
>
>     I'm waiting for your comments.
>
>     [1]
>     http://github.com/rledisez/gallery3/commit/23bb6eb7e35637c8a2124216dbb6d3246ad3d702
>
>     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 ]
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> __[ 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 ]

------------------------------------------------------------------------------
__[ 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]

Yes, that was the wrong approach.

Bharat and I went through the changes and identified a single one that shouldn't be in there.

I've reverted the one commit that shouldn't have been in there.

The master tree is in an OK state again.

I followed the wrong recipe:

http://github.com/guides/pull-requests

...merging in a whole fork. I was lucky that the fork didn't contain much more than what we wanted anyway. Well, not too lucky. I reviewed the changes and if there was more in there that I didn't approve of, I would have noticed the error.

Next time, I'll use cherry-picking and try it first in my own fork of G3.

Thanks,

 - Andy

On Mon, Jul 27, 2009 at 6:37 AM, Bharat Mediratta <bharat@...> wrote:

Andy, how did you integrate this change?  It seems like you pulled in
Romain's entire fork!  This is bad, he's got stuff in there that we
cannot have in our repo, like
http://github.com/gallery/gallery3/commit/c80d2da0a95a63b76f5a4c835f1a0e1022ec2f53
which breaks our sort orders.  I've been carefully cherrypicking his
changes to avoid this.  It also has the complete history of all the
other stuff that Romain tried that we also really don't want in our
history, eg:
http://github.com/gallery/gallery3/commit/923732ca4dca6db218f6252a7133cd72f98fa086
this isn't terrible, but it's really not what we want in our history.

Because of the way that git works, now that it's in our canonical repo
we're kind of screwed.  We can rebase the canonical repo and remove
those changes, but anybody who's done a pull has them, and if any of
*those* people push directly back, then they'll come back again.  The
only way to fix this is to rebase the canonical repo, then either we all
rebase our own repos or we delete them and re-clone and start again.
And that won't fix any non-dev out there who's got a repo who has done a
pull in the meantime (although at least they won't be able to push back
to us).

I'm willing to do this, but I think we'd have to turn off direct push
privileges and only turn them back on when developers assert that
they've cleaned out their repos.  And if anybody has an old repo out
there containing these changes and accidentally pushes in the future,
then we're screwed again.  :-(

I am not sure how much time I have to deal with this today.  Please make
it a priority to review each of the changes from that fork and remove
any of the ones that are not essential for the column rename.

-Bharat

Andy Staudacher wrote:
> Hi Romain,
>
> Great work! I've reviewed the changes and it all looks good.
>
> I've done some sanity checks (grep'ing, running tests). Looks like
> you've covered everything.
> I've also verified that keywords like "count" or "timestamp" are indeed
> no problem in MySQL queries as column names. Makes for fun queries like
> select count(count). :)
>
> I've merged your left / right -> left_ptr / right_ptr changes to the
> master tree.
>
> The one thing I reverted was your change to install.sql which removed
> the charset settings. These would creep back in the next time we do a
> packaging anyway.
> See:
> http://github.com/gallery/gallery3/commit/482e223b602d60eec424081d0328cde66d28a758
>
> Let's continue with these changes. Please let me know when the next
> batch of changes is ready. :)
>
> Thanks,
>  - Andy
>
> On Sat, Jul 25, 2009 at 3:26 PM, Romain LE DISEZ <romain.g3@...

> <mailto:romain.g3@...>> wrote:
>
>     (sorry for the double post, I posted with the wrong address)
>
>     Le 25 juil. 09 à 17:22, Romain LE DISEZ a écrit :
>     >> As for the column names that we should choose. Here are some
>     >> modifications to your proposal:
>     >>
>     >> * items.left                 -> lft, left_val, left_value, left_bound
>     >> * items.right                -> rgt, right_val, right_value,
>     >> right_bound
>     >
>     > I'm going to code that. I will use the proposition of Bharat :
>     > left_ptr and right_ptr. If it gets merged, I will code the rename of
>     > the columns "key" with your proposition (cache_key, msg_key and label)
>
>     I commited it with the upgrade code [1], it's a big diff. The units
>     tests pass and my personals tests also. I ran it on a gallery of about
>     30 albums and 1300 photos. I checked addition, deletion of photos and
>     albums. After each operations I looked the values of left_ptr and
>     right_ptr.
>
>     I'm waiting for your comments.
>
>     [1]
>     http://github.com/rledisez/gallery3/commit/23bb6eb7e35637c8a2124216dbb6d3246ad3d702
>
>     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 ]
>
>
>

> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------

>
>
> ------------------------------------------------------------------------
>
> __[ 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 ]

------------------------------------------------------------------------------

__[ 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 27 juil. 09 à 15:37, Bharat Mediratta a écrit :
> This is bad, he's got stuff in there that we
> cannot have in our repo, like
> http://github.com/gallery/gallery3/commit/c80d2da0a95a63b76f5a4c835f1a0e1022ec2f53
> which breaks our sort orders.

I don't understand how this change can break something. Here is a  
simulation :

     SELECT COUNT(*) AS position FROM items
     WHERE parent_id = 846 AND weight > (SELECT weight FROM items  
WHERE id = 903)
     ORDER BY weight DESC;
=>
     SELECT COUNT(*) AS position FROM items
     WHERE parent_id = 846 AND weight > 27
     ORDER BY weight DESC;

So, the RDBMS will :
1/ filter the rows by parent_id and weight,
2/ count them
3/ order the result of the count

Because COUNT(*) only returns one row, the ORDER BY will sort only one  
row. An ORDER BY with a COUNT(*) just do nothing.

But, reading the code, I think there MUST be an ORDER BY in the query  
following this one. Without and ORDER BY, the result will be aleatory.

I will propose a commit that fix it soon.

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 ]

[Andy Staudacher-3]

True, since it's just a count(), the order by is indeed useless.

The order by should be in the second query.

I'll get to it later today.

BTW: github's web interace is terribly slow lately.

 - Andy

On Mon, Jul 27, 2009 at 1:43 PM, Romain LE DISEZ <romain.g3@...> wrote:

Le 27 juil. 09 à 15:37, Bharat Mediratta a écrit :

This is bad, he's got stuff in there that we
cannot have in our repo, like
http://github.com/gallery/gallery3/commit/c80d2da0a95a63b76f5a4c835f1a0e1022ec2f53
which breaks our sort orders.

I don't understand how this change can break something. Here is a simulation :

   SELECT COUNT(*) AS position FROM items
   WHERE parent_id = 846 AND weight > (SELECT weight FROM items  WHERE id = 903)
   ORDER BY weight DESC;
=>
   SELECT COUNT(*) AS position FROM items
   WHERE parent_id = 846 AND weight > 27
   ORDER BY weight DESC;

So, the RDBMS will :
1/ filter the rows by parent_id and weight,
2/ count them
3/ order the result of the count

Because COUNT(*) only returns one row, the ORDER BY will sort only one row. An ORDER BY with a COUNT(*) just do nothing.

But, reading the code, I think there MUST be an ORDER BY in the query following this one. Without and ORDER BY, the result will be aleatory.

I will propose a commit that fix it soon.

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 ]

[Romain LE DISEZ-5]

Le 27 juil. 09 à 22:48, Andy Staudacher a écrit :

> True, since it's just a count(), the order by is indeed useless.
>
> The order by should be in the second query.

It's not as simple as moving the ORDER BY. It's a nonsense of sorting  
by {$this->sort_column} because of the equality in the WHERE clause.  
We must choose a default sorting for this query. It could be  
"left_ptr" so it will be sorted by upload order.

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:

>
> Le 27 juil. 09 à 22:48, Andy Staudacher a écrit :
>
>> True, since it's just a count(), the order by is indeed useless.
>>
>> The order by should be in the second query.
> It's not as simple as moving the ORDER BY. It's a nonsense of sorting by
> {$this->sort_column} because of the equality in the WHERE clause. We
> must choose a default sorting for this query. It could be "left_ptr" so
> it will be sorted by upload order.

You're totally correct.  I'm pretty sure that this order by used to be
necessary, but now that we've broken this out into an inequality in the
first query, and an equality in the 2nd query, then
1) order in the first query is no longer relevant
2) the order in the second query has to be something other than
$this->sort_column

So for the 2nd query, it's arbitrary what column we choose for the sort
order.  I'm going to opt for id, because it'll provide the most stable
sort order.  I'll go ahead and make that change now.

Thanks, Romain!

-Bharat

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
__[ 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 lundi 27 juillet 2009 à 00:26 -0700, Andy Staudacher a écrit :
> Let's continue with these changes. Please let me know when the next
> batch of changes is ready. :)

It should be OK for caches.key :
http://github.com/rledisez/gallery3/commit/5c468bf9d4db0091de01ef9432cf6d66e899b2fa

Change for messages.key is almost ready, it needs some testing.

It will be a little bit harder for [incoming|outgoing]_translations.key
because there is a lot of references to "key", some need to be changed
and some not.

Greetings.


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
__[ 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 lundi 27 juillet 2009 à 00:26 -0700, Andy Staudacher a écrit :
> Let's continue with these changes. Please let me know when the next
> batch of changes is ready. :)

It's done for messages.key :
http://github.com/rledisez/gallery3/commit/4a92089e75bff5492dda9d2e46ef72867493358f

The tricky part is starting now...

Greetings.



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
__[ 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 28 juillet 2009 à 16:44 +0200, Romain LE DISEZ a écrit :
> It's done for messages.key :
> http://github.com/rledisez/gallery3/commit/4a92089e75bff5492dda9d2e46ef72867493358f

And this one :-(
http://github.com/rledisez/gallery3/commit/1034eb28832585c4b5936052365cc6ea04f82211



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
__[ 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]

Looks good. Going to pick up the changes later today.

BTW: For incoming / outgoing translations, please limit the renaming to the PHP <-> database interface, and don't rename "key" in the JavaScript, HTML, and neither in the l10n_client / server protocol.

Thanks,

 - Andy

On Tue, Jul 28, 2009 at 8:13 AM, Romain LE DISEZ <romain.g3@...> wrote:

Le mardi 28 juillet 2009 à 16:44 +0200, Romain LE DISEZ a écrit :

> It's done for messages.key :
> http://github.com/rledisez/gallery3/commit/4a92089e75bff5492dda9d2e46ef72867493358f

And this one :-(
http://github.com/rledisez/gallery3/commit/1034eb28832585c4b5936052365cc6ea04f82211

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
__[ 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,

Le 28 juil. 09 à 18:20, Andy Staudacher a écrit :
> Looks good. Going to pick up the changes later today.

there is some conflicts with the commit [1] of Tim. I don't know how  
you will merge my fork now, but FYI I resolved the conflict with [2].

Greetings.

[1] ead6a61d9e96d37ca3a0aecb93d18755099e341c
[2] 434ed5dfdeb4348c813bfedc75a36be637245002



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
__[ 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 Andy,

this modification is waiting to be merged for a month now. Is there  
any problem with it, or are you just missing time ?

As a summary :

Modification :
     4a92089e75bff5492dda9d2e46ef72867493358f
     1034eb28832585c4b5936052365cc6ea04f82211

Conflict resolution :
     434ed5dfdeb4348c813bfedc75a36be637245002
     fa266d6c0c64ae1692dfb6bee5e3c63a6413d8f4

Greetings.

Le 28 juil. 09 à 18:20, Andy Staudacher a écrit :

> Looks good. Going to pick up the changes later today.
>
> BTW: For incoming / outgoing translations, please limit the renaming  
> to the PHP <-> database interface, and don't rename "key" in the  
> JavaScript, HTML, and neither in the l10n_client / server protocol.
>
> Thanks,
>  - Andy
>
> On Tue, Jul 28, 2009 at 8:13 AM, Romain LE DISEZ <romain.g3@...
> > wrote:
> Le mardi 28 juillet 2009 à 16:44 +0200, Romain LE DISEZ a écrit :
> > It's done for messages.key :
> > http://github.com/rledisez/gallery3/commit/4a92089e75bff5492dda9d2e46ef72867493358f
>
> And this one :-(
> http://github.com/rledisez/gallery3/commit/1034eb28832585c4b5936052365cc6ea04f82211
>
>
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
__[ 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]

Hi Romain,

This is still in my queue. Sorry about the delays. Had to prioritize the new XSS filtering API.

I'll get back to it shortly.

 - Andy

On Fri, Aug 28, 2009 at 9:58 AM, Romain LE DISEZ <romain.g3@...> wrote:

Hi Andy,

this modification is waiting to be merged for a month now. Is there any problem with it, or are you just missing time ?

As a summary :

Modification :
   4a92089e75bff5492dda9d2e46ef72867493358f
   1034eb28832585c4b5936052365cc6ea04f82211

Conflict resolution :
   434ed5dfdeb4348c813bfedc75a36be637245002
   fa266d6c0c64ae1692dfb6bee5e3c63a6413d8f4

Greetings.

Le 28 juil. 09 à 18:20, Andy Staudacher a écrit :

Looks good. Going to pick up the changes later today.

BTW: For incoming / outgoing translations, please limit the renaming to the PHP <-> database interface, and don't rename "key" in the JavaScript, HTML, and neither in the l10n_client / server protocol.

Thanks,
 - Andy

On Tue, Jul 28, 2009 at 8:13 AM, Romain LE DISEZ <romain.g3@...> wrote:
Le mardi 28 juillet 2009 à 16:44 +0200, Romain LE DISEZ a écrit :
> It's done for messages.key :
> http://github.com/rledisez/gallery3/commit/4a92089e75bff5492dda9d2e46ef72867493358f

And this one :-(
http://github.com/rledisez/gallery3/commit/1034eb28832585c4b5936052365cc6ea04f82211

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
__[ 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 ]