We have several projects in which a one-to-many relationship (cascading on) must be persisted using stored procedures which perform internal auditing; direct CRUD SQL calls are not allowed on any of our tables:



Currently, Hibernate must use its own CollectionPersister and does not allow the definition of a custom Collection persister. Therefore, the paradigm described above works well for the "one" side and for other independent entities, but fails for the "many" side, as Hibernate tries to issue CRUD SQL directly against the table rather than using a custom persister (See HB-326).

We are unable to proceed with Hibernate and may have to migrate to Toplink unless we can resolve this issue. We'd like to hear any suggestions or input on the following:

• What level of difficulty might we be facing if we wanted to do the work to allow custom Collection persisters in Hibernate? We have resources available to work on this change, but we will need some guidance as to the best approach.
• What might make a good workaround for persisting this Set ourselves as cleanly as possible, using as much of what Hibernate provides as possible?

Any input is greatly appreciated.

Cisco Systems EMAN Framework Team

--

Opinions expressed may not reflect the views of Cisco Systems.

Hi,


I have currently on my TODO list:

"Make CollectionPersister an interface"


This is not hard to do ;)


Take a look at the net.sf.hibernate.collection package. In particular, decide if you would be able to make a custom CollectionPersister that would work in your environment.


If so, I will accept changes to the collections package to allow this.

Can you provide a rough idea of the timeframe in which this could happen? If your TODO list is anything like mine..... ;-)

Also, if we do decide to bite off doing the work ourselves, this implies we'd have to change the XML config syntax a bit. Can you give any pointers on best practices there with respect to style, syntax and so-on and maybe some direction on where those changes would have to be made?

Thanks,

Nick

I work with spatula and since we are going to blocked on this problem I thought I'd post a couple of suggestions.

For a long term fix I think the extract interface refactoring w/ being able to specify a custom collectionpersister is the right thing to do.


For the shorter/near term I would think it should be possible for the current implementation of CollectionPersister to detect that the collection is specified using the "class" tag on the one-to-many element. If it can look up to see if that class has a custom persister defined for it and use it instead of issuing SQL clauses directly then we have a way of making it a bit more transparent for the developers using our persistable classes.

In pseudoCode for the insertRows(collection, id, session) method



Gavin, does this look reasonable? I can try to bang my head on getting this to work if it does (it's the first time I've been into the bowels of hibernate)

- Jason

I think we decided last week that Max will own this stuff. He's keen to build some proper support for a StoredProcedurePersister into Hibernate.


For a temporary fix, you might be able to do something with custom types. You don't have to use Hibernate's built in collection support.

I think we are having a difficulty communicating this problem precisely over the bulletin board. We decided that it would go much quicker if we could talk to you. I will set up a meetingplace phone bridge with you and/or Max with our team (Me, Rob and Nick aka 'spatula') if you can supply me contact info.

This is really rather important for us (enough so that it would kill this pilot with Hibernate) and we are very willing to commit resources to getting it resolved.

Please send email with contact info to my email at jasonkrue@hotmail.com and whatever time/date that would be most convenient.

Thanx
- Jason, Nick and Rob
Enterprise Management Team at Cisco Systems, Inc.

FYI: I've contacted jason via email