Ticket #536 (Closed: fixed)
reading UniqueIds in PostgresqlSchedule generally wrong
| Priority: | normal | Reporter: | maroy |
|---|---|---|---|
| Severity: | minor | Assigned to: | fgerlits |
| Component: | bug | Status: | closed |
| Version: | Resolution: | fixed | |
| Milestone: | Keywords: |
Description by maroy:
in PostgresqlSchedule?, reading the unique ids from the database is generally done as follows: Ptr<UniqueId>::Ref id(new UniqueId(rs->getLong(1))); this is wrong, as the ids don't fit into a long, while rs->getLong() tries to restrict it to long. a possible way to work around this problem is to read the ids as string, and convert the string to long long values. rs->getString() for numeric values returns then in decimal, thus I created UniqueId?::fromDecimalString() to do the job, as the UniqueId(const std::string) constructor expects a hexadecimal value. I've fixed reading the ids in PostgresqlSchedule? according to the above workaround. now the general way for reading the ids is: Ptr<UniqueId>::Ref id = UniqueId?::fromDecimalString(rs->getString(1)); maybe this should be changed in other classes, which also read unique ids from the database via ODBC++. also, I haven't checked on writing out ids. there might be a nicer way to approach this problem by extending ODBC++ to include a ResultSet?::getLongLong() function.
Attachments
Changelog
Mon Jan 10 16:37:27 2005: Modified by fgerlits
Mon Jan 10 17:03:03 2005: Modified by maroy
- owner changed from fgerlits to maroy
Mon Jan 10 17:07:33 2005: Modified by maroy
strangely enough, the very reason for the configure test failing is that there's a strtoll in stdlib.h. the corresponding excerpt from config.log: configure:9352: checking for strtoll configure:9395: g++ -o conftest -D_GNU_SOURCE -g -O2 conftest.cc >&5 configure:9367: error: declaration of C function `char strtoll()' conflicts with /usr/include/stdlib.h:362: error: previous declaration `long long int strtoll(const char*, char**, int)' here configure:9367: warning: inline function `char strtoll()' used but never defined configure:9367: warning: inline function `char strtoll()' used but never defined configure:9398: $? = 1 configure: failed program was: #line 9357 "configure" #include "confdefs.h" /* System header to define stub macros and hopefully few prototypes, which can conflict with char strtoll (); below. */ #include <assert.h> /* Override any gcc2 internal prototype to avoid an error. */ #ifdef cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char strtoll (); char (*f) (); #ifdef F77_DUMMY_MAIN # ifdef cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with and the normal name is
an alias. */ #if defined (stub_strtoll)
Tue Apr 5 00:08:52 2005: Modified by maroy
the solution was to use a newer version of autoconf to create the configure script for libodbc++, so that stroll() and strtoq() will be detected properly. for a related bugreport in the libodbc++ tracker, see: https://sourceforge.net/tracker/index.php?func=detail&aid=1176 660&group_id=19075&atid=119075 also posted two other bugreports with fixes to the libodbc++ tracker: https://sourceforge.net/tracke r/index.php?func=detail&aid=1176648&group_id=19075&atid=119075 http s://sourceforge.net/tracker/index.php?func=detail&aid=1176655&group_id =19075&atid=119075
Tue Apr 5 00:11:40 2005: Modified by maroy
I reverted back to handling IDs in a numeric manner. Ferenc, could you double-check my changes in PostgresqlScheduler? and PostgresqlPlayLog?: http://netfinity-5.mdlf.org/cgi-bin/viewcvs.cgi/livesupport/products/s cheduler/src/PostgresqlSchedule?.cxx.diff?r1=1.10&r2=1.11 http://netfinity-5.mdlf.org/cgi-bin/viewcvs.cgi/livesupport/products/s cheduler/src/PostgresqlPlayLog?.cxx.diff?r1=1.5&r2=1.6 thanks...
Tue Apr 5 00:11:49 2005: Modified by maroy
- owner changed from maroy to fgerlits
Tue Apr 5 09:42:08 2005: Modified by maroy
see attached try.cxx to reproduce the problem
Wed Apr 6 12:30:09 2005: Modified by fgerlits
- resolution set to fixed
- status changed from assigned to closed
Looks fine to me.
Wed Apr 6 12:32:56 2005: Modified by maroy
ok, closing then...
This should have worked as was written, because getLong() does not return a long; it returns a Long, which is a typedef for long long. The problem is that when odbc++ converts from a string to a Long, it checks the environment variable ODBCXX_HAVE_STRTOLL set by its configure script; if it believes strtoll() to be present, it uses that, otherwise falls back to strtol(). See the src/dtconv.h file in the tarball. For some reason, the configure script does not find strtoll() (which is present on ls-dev, in stdlib.h), and sets this environment variable wrong.