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