Re: Does Cayenne handle binary primary keys (Sybase) in relationships?

From: Michael Gentry (michael_gentr..anniemae.com)
Date: Wed Oct 22 2003 - 22:11:40 EDT

  • Next message: Andriy Shapochka: "Re: Does Cayenne handle binary primary keys (Sybase) in relationships?"

    I just ran it and it worked! OK, so the logging of the bytes is a
    little misleading currently, but the relationships work now. I can do
    some more extensive testing of our model, however our binary PKs (and
    FKs) were definitely the big stress test in our schema.

    Thanks for the help, Andrus!

    /dev/mrg

    Andrus Adamchik wrote:

    > Ok, here is another patched download:
    >
    > http://objectstyle.org/downloads/cayenne/patched/cayenne-src-
    > 1.0.1p3.tar.gz
    >
    > Of course this is cumulative, i.e. newer "patched" versions contain
    > fixes made earlier.
    >
    > I've tested a few scenarios working with binary PK/FK. Everything
    > seems to work just fine. I even created a binary PK generator (for
    > test purposes only, it is rather ugly and uses
    > java.lang.reflect.Proxy to intercept calls to a normal PK Generator).
    > I will see if I can include a working generator in 1.0.2. This will
    > take some time though.
    >
    > Andrus
    >
    >
    > On Wednesday, October 22, 2003, at 04:09 PM, Andrus Adamchik wrote:
    >
    >> Hi Michael,
    >>
    >> I think I might know what is causing the latest problem. ObjectId is
    >> used as a key to identify objects in the ObjectStore. So as a map
    >> key it must have a properly implemented hashCode() method. With
    >> String or numeric PKs hashCode() works since it relies on
    >> AbstractMap.hashCode() implementation. With byte[] it does not,
    >> since default hashCode for arrays of primitives seems to be based on
    >> identity rather than element equality. In fact I just wrote a test
    >> case that confirms my suspicion.
    >>
    >> I will do some more testing, and see how to create a smarter
    >> hashCode implementation. I'll keep you posted.
    >>
    >>> PS. Also, "80 80 80 80 80 80 80 A2 CC 20 EE C9" is different than
    >>> yesterday's "[0, 0, 0, 0, 0, 0, 0, 34, 76, -96, 110, 73]" ... 0x80
    >>> != 0. 0xA2 != 34 ...
    >>
    >>
    >> Umm, yeah... I am converting each byte to an unsigned form before
    >> converting it to HEX, by adding 128 (-Byte.MIN_VALUE). This does
    >> look a bit odd... I am open to suggestions on the logging format.
    >>
    >> Andrus
    >
    >
    >

    This archive was generated by hypermail 2.0.0 : Wed Oct 22 2003 - 22:11:47 EDT