I'm wondering if idbag will support identity keys in the future

And if so, when that feature is planned

"yes", and "no comment"

Now that 2.1 is out, I'm wondering if this can be put in the roadmap?

I think "no comments" was the answer to this and related questions :)

I desperately want this feature

I will help in anyway that I can

well, you are welcome to look into producing a patch - it is not quite trivial, but probably not especially difficult, I'm not sure

Look at IdentifierBag class.

I'm looking at the code for:
net.sf.hibernate.collection.IdentifierBag


I'm still a bit lost.

I'm guessing that if I get to an understanding of how it works
for other id types, that I'll get closer to understanding what's
missing to make identity ids work

Is there another id type I should look at?

IdentifierBag assigns ids to new elements in the PersistentCollection.preInsert() call. Obviously, this will not work for identity columns, You need to find some way to have the ids assigned by AbstractCollectionPersister.insertRows() and AbstractCollectionPersister.recreate()

I see that in both
AbstractCollectionPersister.insertRows()
and
AbstractCollectionPersister.recreate()

there is a call to
PersistentCollection.afterRowInsert()


This seems to be a hook that was added for the purpose
of identity ids

But it I don't see how the auto-assigned id will be propogated
to that call.

I've made enough changes to

AbstractCollectionPersister
BasicCollectionPersister
IdentifierBag

in order to not try to write the id during the insert


I still need to retrieve the id after insert though


What's weird is the following test case:

Query q = session.createQuery("select hawb from test.TestHawb hawb where hawb.hawb='TEST'");

TestHawb hawb = (TestHawb)q.list().get(0);

TestRef ref = new TestRef();
ref.setRef("REF4");

hawb.getRefs().add(ref);

session.flush();

System.out.println("Hawb: " + hawb.getHawb());

for(Iterator i = hawb.getRefs().iterator(); i.hasNext(); ) {
//TestRef
ref = (TestRef)i.next();

System.out.println("Ref: " + ref.getRef());

ref.setRef(ref.getRef() + "tim");
}

session.flush();
session.close();


where there are already three children persisted
produces the following output:

Query "select testhawb0_.id as id, testhawb0_.hawb as hawb from test_hawb testhawb0_ where (testhawb0_.hawb='TEST' )" execution time: 0 result set fetch time: 0
Query "select refs0_.ref as ref__, refs0_.hnu as hnu__, refs0_.ID as ID__ from test_refs refs0_ where refs0_.hnu=1" execution time: 0 result set fetch time: 0
insert into test_refs (hnu, ref) values (?, ?)
net.sf.hibernate.id.IdentityGenerator@e64686
Query "insert into test_refs (hnu, ref) values (1, 'REF4')" execution time: 0
Hawb: TEST
Ref: REF1timtim
Ref: REF2timtim
Ref: REF3tim
Ref: REF4
Query "update test_refs set ref='REF1timtimtim' where ID=2" execution time: 0
Query "update test_refs set ref='REF2timtimtim' where ID=3" execution time: 15
Query "update test_refs set ref='REF3timtim' where ID=4" execution time: 0
Query "update test_refs set ref='REF4tim' where ID=4" execution time: 0



I do not understand why the fourth child uses the same id as the third

I would think that the fourth child would still have
IdentifierGeneratorFactory.IDENTITY_COLUMN_INDICATOR
for an id

I don't really understand the purpose of
PersistentCollection.afterRowInsert()

since this is being called from

AbstractCollectionPersister.insertRows()
and
AbstractCollectionPersister.recreate()

after adding the PreparedStatement to a batch

the row hasn't necessarily been inserted yet

I could see adding the Batcher as an arg to
afterRowInsert()

Then afterRowInsert() could force the batch
and retrieve the generated ids

The Batcher would have to have a public getter for
the PreparedStatement

This would allow afterRowInsert()
to call doExcuteBatch()
and then call getGeneratedKeys() on the Statement

I've talked to mm_mysql on irc://irc.freenode.net/hibernate

It would be possible to make the getGeneratedKeys()
method on a PreparedStatement return a ResultSet
that add all the keys for the just executed batch



My question is:
Would the hibernate project accept patches that used getGeneratedKeys() ?

There is an existing patch like this in JIRA, which I will probably integrate soon. But I wouldn't want to use it for this problem. This functionality should work in JDK 1.2.