Results with OJB 0.9.7: totally different to 1.0rc5, also totally broken. Someone throw me a bone? :-(

OK, so I added all the field-desctipor id's and reference id's that 0.9.7 requires, deleted then index-descriptor's that 0.9.7 doesn't recognise, and added properties for everything I was using anonymous access for and added public constructors/accessors/mutators until I wasn't getting errors any more. The result was the exact same code producing completely different results:

- the first insert, where the object already exists in the database, produced no errors with 097, where clearly it should have failed (and did with CVS HEAD and 1.0rc5, though not where I expected)

- the second and third inserts succeeded without error, but did nothing to the database; either an error should have occurred or the object should have been persisted

- the fourth and fith inserts similarly had no errors and no effect

- the deletes did nothing, despite executing the following SQL (as reported by p6spy):
1080191046253|4|0|statement|DELETE FROM PLAYER WHERE ID = ? |DELETE FROM PLAYER WHERE ID = '0'
1080191046256|1|0|commit||
(and yes, a record with ID=0 did exist in the database both before and after OJB 097 ran this SQL)


- the final delete (creating an object that didn't exist in the database and calling deletePersistent() on it) also succeeded without error, but did nothing despite executing the same SQL at above

Maybe tomorrow I'll zip up all the code and config files from the 1.0rc5 and 097 tests I've done in case I've left something out in this thread. At this point I've done everything I can think of to understand what's going wrong short of single-stepping though everything in a debugger. There *must* be problems in my repository descriptor and/or the code I'm writing; I had this stuff working last time I used it on OJB 0.9.7.

Help? :-/

L.

Laurie Harper wrote:

OK, I just built OJB from CVS and it's still broken. The first insert throws an exception as described below; the second succeeds and the third, which should fail, hsa no effect. I extended my test code a little further as well with even worse results:

I added code to start another transaction, create another player object, insert it, commit and repeat (new trasaction, re-create an identical player object, insert and commit). I expected a successful insert followed by a failure, but neither of these inserts had any effect what-so-ever.

I also added code to try deleting a player object that doesn't exist in the database. It too has no effect.

I'm going to try downgrading to an older OJB release, since I've used it successfully in the past. If I get the same behaviour from that, at least I'll know� it's me that's buggy instead of OJB ;-)

L.

Laurie Harper wrote:

Is there more information I can provide so someone can help me understand what I'm doing wrong here? I'm completely blocked at the moment :-(

To re-iterate:

- persisting new objects which collide with previously existing objects results in an error, but not where I'd expect

- persisting multiple objects to the database that violate unique constraints doesn't raise any errors

- I can't delete newly inserted objects; OJB keys on column data it doesn't have available

Currently, this means that data entry is intrinsically unreliable in my app, since the data you just entered may or may not ever make it into the database, and I can't recover from errors by cleaning up earlier transactions because deletes don't work.

Any help would be appreciated.

L.

Laurie Harper wrote:

What are the expected semantics for object insertion? I'm a bit confused by what I'm seeing here Here's some sample code:

Player p1 = null, p2 = null, p3 = null;

    Implementation odmg = OJB.getInstance();
    Database db = odmg.newDatabase();
    db.open("repository.xml", Database.OPEN_READ_ONLY);

    try {
        System.out.println("insert p1 (pre-existing)");
        p1 = new Player("name1", "player11", "pwd");
        Transaction txn = odmg.newTransaction();
        txn.begin();
        txn.lock(p1, Transaction.WRITE);
        System.out.println("commit");
        txn.commit();
        System.out.println("ok");
    } catch (Throwable t) {
        System.out.println("got a "+t.getClass().getName());
    }

    try {
        System.out.println("insert p2 (new)");
        Transaction txn = odmg.newTransaction();
        txn.begin();
        p2 = new Player("name3", "player3", "pwd");
        txn.lock(p2, Transaction.WRITE);
        System.out.println("insert p2 (again)");
        p3 = new Player("name3", "player3", "pwd");
        txn.lock(p3, Transaction.WRITE);
        System.out.println("commit");
        txn.commit();
        System.out.println("ok");
    } catch (Throwable t) {
        System.out.println("got a "+t.getClass().getName());
        t.printStackTrace();
    }

    System.out.println("clean-up");
    try {
        Transaction txn = odmg.newTransaction();
        txn.begin();
        db.deletePersistent(p2);
        txn.commit();
    } catch (Throwable t) {
        System.out.println("got a "+t.getClass().getName());
    }

    db.close();
}

Assume player1 exists and player3 doesn't. I'm getting several surprises with this.

First, the insertion of player1 fails, as it should. But I expected it to fail on the call to lock(). It doesn't fail until the commit() at which point I get a org.apache.ojb.odmg.TransactionAbortedExceptionOJB. Is this the expected behaviour?

Next, the insertion of player3. This succeeds. What I was expecting was an error on the second call to lock(). I could see it failing in commit() instead for consistency with what I saw on player1, but it ought to fail somewhere shouldn't it?

Finally, the call to deletePersistent is having no effect. I'm unable to delete objects after I insert them. Am I doing something wrong or is this an OJB bug?

I suspect some or all of these problems may be to do with OJB's primary key handling. I'm using database native sequences and OJB seems not to cope with that correctly, going on the SQL statements P6Spy is reporting:

1079658237422|1|0|statement|SELECT password,email,name,ID FROM PLAYER WHERE ID = ? |SELECT password,email,name,ID FROM PLAYER WHERE ID = ''
[from the first call to lock() on player3; the second call generates no SQL]


1079658237473|2|0|statement|DELETE FROM PLAYER WHERE ID = ? |DELETE FROM PLAYER WHERE ID = ''
[on the call to deletePersistent, which explains why it's not doing much]


ID is an anonymous property on Player; could that be a factor? Here's the repository entry for the class:

<class-descriptor
    class="net.holoweb.ff1.domain.om.game.Player"
    table="PLAYER"
 >
    <field-descriptor
        name="ID"
        column="ID"
        jdbc-type="INTEGER"
        primarykey="true"
        nullable="false"
        indexed="true"
        access="anonymous"
    >
    </field-descriptor>
    <field-descriptor
        name="name"
        column="name"
        jdbc-type="VARCHAR"
        nullable="false"
        length="64"
    >
    </field-descriptor>
    <field-descriptor
        name="email"
        column="email"
        jdbc-type="VARCHAR"
        nullable="false"
        length="64"
    >
    </field-descriptor>
    <field-descriptor
        name="password"
        column="password"
        jdbc-type="VARCHAR"
        nullable="false"
        length="64"
    >
    </field-descriptor>
    <index-descriptor
        name="IDX_PLAYER_1"
        unique="true"
    >
        <index-column name="email"/>
    </index-descriptor>
</class-descriptor>

If you need more info to diagnose what's going on, let me know.

L.



--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to