We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.

Bug 3831 - can't reorder membership in a masthead group with postgres
can't reorder membership in a masthead group with postgres
Product: OJS
Classification: Unclassified
Component: Journal Management
PC Linux
: P1 normal
Assigned To: PKP Support
Depends on:
  Show dependency treegraph
Reported: 2008-10-22 10:18 PDT by David Kaloper
Modified: 2013-05-29 15:21 PDT (History)
4 users (show)

See Also:
Version Reported In:
Also Affects:


Note You need to log in before you can comment on or make changes to this bug.
Description David Kaloper 2008-10-22 10:18:24 PDT
When trying to use the little arrows on manager/groupMembership/{group} pages, the operation fails with:

DB Error: ERROR: invalid input syntax for type double precision: "-1,5"

This happens only when using hr_HR interface locale, while everything goes smoothly under English, German, Italian and French.

debug trace and with:

(postgres7): UPDATE group_memberships SET seq = ?, about_displayed = ? WHERE group_id = ? AND user_id = ?   [ (0=>'-1,5') (1=>'1') (2=>'4') (3=>'14') ]

call chain ends with:

File: /var/www/suvlin/htdocs/classes/group/GroupMembershipDAO.inc.php line 135

Function: DAO->update("UPDATE group_memberships SET seq = ?, about_displa...", Array(4))
Comment 1 Matthew Crider 2008-10-22 10:48:34 PDT
See also http://pkp.sfu.ca/support/forum/viewtopic.php?f=8&t=3657 .  It looks like some attributes in Postgresql are being set as doubles when they should be integers.
Comment 2 David Kaloper 2008-10-22 13:44:15 PDT
Seen it.

They shouldn't be integers, in both cases the values are seriously floating-point (and, in my case, hardcoded in OJS as such).

But notice that a) in both cases, the error is limited only to some locales; and b) in both cases, the floating "point" is a treacherous comma instead.

I'm thinking, some locale info is leaking down to database layer, changing string representation of numbers where it most positively shouldn't -- in values bound to queries.

Comment 3 Matthew Crider 2008-10-24 15:47:45 PDT
Hi David,

Thanks for your help in tracking down this problem.  You're quite right that 'seq' is a float (though I'm not sure why--We wouldn't have this problem if they were integers, and I'm not sure what the rationale behind them being floats are).  But you're also right that the number (1.5) is hardcoded in to OJS--and, as far as I can tell, all calls to getSequence() or setSequence() do NOT call for a localized value.  Unless I'm missing something, I believe its another layer between OJS and the database that is causing the problem.  Specifically, are you using Zend?  This bug report caught my attention: http://devzone.zend.com/node/view/id/2324#Heading8
FYI, I wasn't able to reproduce this behavior on my postgres OJS instance (OJS 2.2.0, PostgreSQL 8.3, PHP 4.4.7).
Comment 4 Alec Smecher 2008-10-27 09:27:53 PDT
The seq column is a float simply for convenience in updating it; that's a kludge, not a bug. The problem is that PHP is formatting numeric data using the locale conventions, which apparently means using a , instead of a . in floating-point numbers when the hr_HR locale is used. PostgreSQL is not able to understand these conventions. I'll look into it further.
Comment 5 Alec Smecher 2008-10-27 09:48:37 PDT
David, there appears to be code in ADODB to catch this situation (see, for example, approx. line 827 in lib/adodb/adodb.inc.php). What version of OJS are you using, and have you made any modifications? Are you able to use other up/down arrows elsewhere in the system, e.g. on the Site Administrator's "Hosted Journals" list?
Comment 6 Alec Smecher 2008-10-28 09:47:03 PDT
What version of PHP are you using? After further investigation, it appears that PHP's pg_query_params function is misbehaving along the lines described at <http://bugs.php.net/36606>.
Comment 7 Daniela Dragone 2008-10-28 09:54:23 PDT
(In reply to comment #6)
> What version of PHP are you using? After further investigation, it appears that
> PHP's pg_query_params function is misbehaving along the lines described at
> <http://bugs.php.net/36606>.
I am in CC...
I use PHP 5.2.0-8+etch11

Comment 8 Alec Smecher 2008-10-28 12:42:00 PDT
This is indeed a PHP bug, but it's not #36606. I've confirmed the same behavior both in PHP 5.2.1 and 5.2.6 on my machine. I've filed this as bug #46408 <http://bugs.php.net/bug.php?id=46408>. Marking as invalid against OJS/OCS.
Comment 9 Alec Smecher 2008-10-29 15:40:28 PDT
This has been deemed bogus against PHP for the moment; hopefully this will change, but in the meantime I've posted a patch for ADODB that should work (but needs testing). See <http://phplens.com/lens/lensforum/msgs.php?id=17698>.
Comment 10 MJ Suhonos 2009-07-03 17:35:26 PDT
Reopening this issue as a bug against ADOdb.  Patch provided at:

Comment 11 Alec Smecher 2009-09-15 10:44:25 PDT
Unfortunately, this is *still* open against both PHP and ADODB. Deferring. It should be fixed IMO in both of those projects, not here -- but leaving the bug open as a tracking reminder anyway.