>Is there any plans to support mapping to stored procedurs
>for INSERT, SELECT, UPDATE, and DELETE?
No, not yet.
>What is required to implement this feature?
Well, I've often wondered if the interface(s) to
cirrus.hibernate.impl.ClassPersister
cirrus.hibernate.impl.CollectionPersister
used by SessionImpl could be abstracted, making Hibernate much more modular
internally. I hadn't done this because
(a) nobody had asked for such a feature + I am following an XPish approach
(b) there was no way to abstract ClassPersister + CollectionPersister to
a common interface (collections + entities behave *too* differently)
But if I was to do something like adding interfaces
EntityPersister
AbstractCollectionPersister
then you would probably be able to implement your
StoredProcedureEntityPersister with a moderate amount of straightforward
coding.
Even better, I would start feeling a lot better about the modularity of the
internal design.
Let me spend a couple of days thinking this through. The interfaces of
ClassPersister + CollectionPersister are necessarily quite complex but we
might need only 50% of the interface to provide 90% of the functionality.
(The other methods being used only by the query language parser .... and we
wouldn't be able to support queries upon stored procedures.) I don't
imagine that this would require that much work on my side of things.
I guess my eventual goal for the internal interfaces would be roughly
something like this:
SessionImplementor : provides access to session state
PersisterCache : provides access to compiled mappings (persisters)
QueryImplementor : query parsing + execution
EntityPersister : persistence for entities
AbstractCollectionPersister : persistence + GC for collections
I have cc'd this message to the devel list to see if anyone else has any
good uses for such an idea. (hope you dont mind)
peace
Gavin
|
