[Zope] A Suitable RDBMS?

Hung Jung Lu hungjunglu@hotmail.com
Thu, 16 Mar 2000 08:51:48 PST


bill anderson <bil-@libc.org> wrote:
original article:http://www.egroups.com/group/zope/?start=26253
>Hung Jung Lu wrote:
> > My experience with SyBase is that the adapter development is
> > kind of slow, and only Linux platform is supported. And
> > currently it has some glitches with some data types (decimal
> > with 10 or more digits), it does not support stored procedures,
> > and the implementation in Zope 2.1.4 crashes when you have
> > date fields ending between 59 and 60 seconds (e.g: 59.23 sec).
> > Also, when there is database problem, the adapter very often
> > just hangs and lock the database out, requiring a Zope reboot.
>
>Can you provide more specific detials? I am running two seperate systems
>with Sybase, one of which is pounded on pretty hard, with zero problems.

Sure, you just need to trace my previous postings. :)

SyBase adapter has two specific problems that I have ran
into. They are both 100% reproduceable and both have been
reported to the Collector. One of them is now fixed for
Zope 2.1.5 (the _validTime thing.) The other one still sits
still waiting for Digicool to fix it. If I say the development
of the adapter has been slow, it's because it's been slow. If
I alone have been able to find (and fix) two problems
and one limitation, somehow I don't think they are the
only problems and limitation. :)

Some of the bugs are later found independently by other
people, too. (See below.)

Many people also say that they have zero problems with
Microsoft Windows. I guess they just have been lucky. Ha ha.
But just because one person is lucky, it doesn't mean the
rest of the world is equally lucky. :) Let me teach you
how to para-phrase your question:

"Can you provide more specific details? I am running two
separate system with Sybase, and I would like to know more
about these problems."

Very nice. The following are three articles in chronological order.

regards,

Hung Jung

==============================================================================

"hung jung lu" <hungjungl-@hotmail.com> wrote:
original article:http://www.egroups.com/group/zope/?start=22495
> >From: Christopher Petrilli <petrilli@digicool.com>
> >
> >Can you please specify what the exact behaviour problem IS?  We treat any
> >NUMBER data type with DECIMAL(10,0) or greater as a python long because 
>it
> >can not be represented accurately in a 32-bit integer.  The option (as 
>was
> >treated before) is to return a float, but this is losing accuracy.
>
>----------------------------------------------------------------
>
>:) Sure enough, the DECIMAL data type problem persists in
>SybaseDA-2.0b2.
>
>----------------------------------------------------------------
>
>:) I nagged quite a bit in the zope mailing list about the
>SybaseDA DECIMAL data type problem, even posted a patch for it.
>Chris McDonough was kind enough to send everything to the
>Collector, too. The relevant threads can be views at
>Egroups.com under
>
>http://www.egroups.com/group/zope/showthread.html?start=21025
>http://www.egroups.com/group/zope/showthread.html?start=21108
>
>----------------------------------------------------------------
>
>It is very easy to cause the crash. Install your SybaseDAv2,
>restart Zope, create (add) an instance of "Sybase DataBase
>Connection", click on it, make sure that is it connected.
>Now, go to the "Test" tab, issue the SQL command:
>
>    create table test (id decimal(10))
>
>Hit "Submit Query". Good. The table is created. Now, go
>to the "Test" tab again, issue the SQL command:
>
>    select * from test
>
>Voila, crash.
>
>     Error Type: sy_occ.error
>     Error Value: Invalid buffer element type
>     ...
>     File /usr/local/bs_zope/lib/python/Products/SybaseDAv2/db.py, line 
>239, in query
>     sy_occ.error: (see above)
>
>The error does not happen when you have 9 or fewer digits
>in your DECIMAL data type declaration.
>

==============================================================================
"hung jung lu" <hungjungl-@hotmail.com> wrote:
original article:http://www.egroups.com/group/zope/?start=22504
>Hi,
>
>There is a bug in \lib\DateTime\DateTime.py, this particularly concerns 
>Sybase database users. In the lines:
>
>     def _validTime(self,h,m,s):
>         return h>=0 and h<=23 and m>=0 and m<=59 and s>=0 and s<=59
>
>Please change s<=59 to s<60.
>
>This bug is causing Sybase to crash whenever a table contains a date value 
>with s>59, e.g: s=59.23
>
>regards,
>
>Hung Jung
>(I have submitted to the Zope bug collector)
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
>
>
>_______________________________________________
>Zope maillist  -  Zope@zope.org
>http://lists.zope.org/mailman/listinfo/zope
>**   No cross posts or HTML encoding!  **
>(Related lists -  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope-dev )
>

==============================================================================

brian takashi hooper <bria-@garage.co.jp> wrote:
original article:http://www.egroups.com/group/zope/?start=23843
>Hi there -
>
>(I've taken the liberty of also submitting these bugs to the Collector...)
>
>I think I found a bug with ZSybaseDA (the newest version) - here's the
>deal:
>
>I have a table in Sybase with a DateTime field.
>When I get a time back from it, the value of the field gets set in
>sy_occbf.c to something like:
>
>(2000, 2, 21, 22, 31, 59.63)
>
>The second value is being set to double (on purpose, looking at the
>sy_occbf.c code).
>
>The problem with this is that DateTime doesn't correctly validate
>floating point hour/min/seconds.  The documentation string seems to say
>that DateTime can take (from the DateTime 1.43 doc string)
>
>"floating point, positive or negative offsets in units of hours, minutes,
>and days,"
>
>for the fourth, fifth and sixth arguments - should this instead be
>
>"positive integer values for hours, minutes, and positive floating point
>values for seconds"?
>
>I think the latter might be simpler and easier to understand...
>Anyways, right now what DateTime is closer to this anyway - it validates
>times by calling self._validTime(h, m, s), which is defined:
>
>     def _validTime(self,h,m,s):
>         return h>=0 and h<=23 and m>=0 and m<=59 and s>=0 and s<=59
>
>I was lucky enough to stumble on the case where 59 < s < 60; this could
>be taken care of by:
>
>     def _validTime(self,h,m,s):
>         return h>=0 and h<=23 and m>=0 and m<=59 and s>=0 and s<60.0
>
>Of course, it's obvious that negative hour or minute offsets are also
>not going to work...
>
>The Sybase DA end of the thing - as I started out by saying, I noticed
>all this because the results that Sybase returned didn't convert
>correctly.  Specifically, an exception was raised where SybaseDA was in
>the middle of handling a fetched result set:
>
>(in db.py, DA.query()...)
>
>if type(v) is TupleType:
>     v=apply(converters[t], v)
>
>Because an exception is raised in the middle of fetching a result set,
>the command structure still has results left to fetch - this makes the
>next call to cm.ct_command() fail - Sybase says, on the next query:
>
>ct_command(): user api layer: external error: This routine cannot
>be called while results are pending for a command that has been sent to
>the server.
>
>Which happens because we never got to cancel the previous result set.
>
>How about running the conversions in a try/except, for safety, like:
>
>try:
>     if type(v) is TupleType:
>         v=apply(converters[t], v)
>except:
>     cm.ct_cancel(sy_occ.CS_CANCEL_ALL)
>     raise Error("Results field conversion error: converter=%s, v=%s" % \
>                 (str(converters[t]), str(v)))
>
>I don't think there is anything else, but anything that might throw an
>exception in the error processing loop should also probably be wrapped
>to call ct_cancel so that the command structure is ready to go on the
>next call.
>
>Well, that's all.  This'll be in the Collector as soon as I can write it,
>too.
>
>-Brian Hooper
>
>_______________________________________________
>Zope maillist  -  Zope@zope.org
>http://lists.zope.org/mailman/listinfo/zope
>**   No cross posts or HTML encoding!  **
>(Related lists -  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope-dev )

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com