Just for reference - Timothy has been working on a hibernate based persistence facility for Merlin which I'll commit into sandbox tommorow - it seems to me that this may be rather relavant to this discussion.
Stephen.
andreas oberhack wrote:
-----Original Message-----
From: andreas oberhack [mailto:[EMAIL PROTECTED] Sent: Sonntag, 15. Februar 2004 18:23
To: 'hammett'
Subject: RE: [Proposal] Augmenting Fortress extensions support
I'm also very, very! much interested in persistence and transaction management in Avalon/Merlin. I just got the opportunity to build a technical prototype for a huge enterprise project, which I will build on Merlin.
I also have implemented a persistence integration into Merlin. So let's join ideas!
First of all my question: why don't you use a mapping framework like Hibernate or OJB? My motivation behind that question is, that "transparency" not only touches the question of transactions! "Transparency" should also cover navigation, type handling, auto key generation etc, etc. There also should be easy to use query capabilities, so that "persistence" is transparent and not only transactions.
Also one should have a great flexibility in handling transactions. You should be able to rollback transactions by business rules etc.
So I went an other way. I have implemented a "UserContext" which is in fact a subclass of normal Context in Merlin. This UserContext is pluggable like ever other service in Merlin.
This UserContext and it's interface is the only thing, a developer needs to persist beanstyled business objects. An example: (not fully functional :-) )
trx = UserContext.startTransaction(); trx.insert(businessObject); trx.commit();
to query objects:
trx = UserContext.startTransaction();
q = UserContext.setQuery("select * from businessObject"); // iterate
BusinessObject obj = (BusinessObject)q.next();
Object.setName("Bruno");
Trx.commit();
All queried objects "know", that they are "persistence capable".
Navigation between objects is done automatically using normal java collections.
Mapping and creation of database tables is done automatically. I have also started to implement a eclipse plugin, so that you only need to select the classes which you like to be persistent in a Merlin component and all other things are generated automatically: mapping files, javadoc tags, the appropriate context in Merlin etc.....
The need thing in that approach is that I didn't need to change anything in Merlins interfaces!!
So this solution is not figured out perfectly - but I think it's very good starting point for maximum of persistence - transparency, ease of use, flexibility and stabability.
I really would like to hear your thoughts!
Andreas
-----Original Message----- From: hammett [mailto:[EMAIL PROTECTED] Sent: Sonntag, 15. Februar 2004 17:16 To: Avalon Developers List; [EMAIL PROTECTED] Subject: Re: [Proposal] Augmenting Fortress extensions support
----- Original Message ----- From: "andreas oberhack" <[EMAIL PROTECTED]> To: "'Avalon Developers List'" <[EMAIL PROTECTED]> Sent: Sunday, February 15, 2004 4:32 AM Subject: RE: [Proposal] Augmenting Fortress extensions support
Let me try to understand your requirements first. I assume, that you
are
talking about transactions to persist objects?
Yup. I'm trying to push Avalon a loosely couple BO framework. Then I'd like to start in little steps :-)
- There is a no extension for each method call
And you would like to declare a transaction per method call, so that
the
transaction context could be set automatically?
Exactly. See my article about JTA: http://www.apache.org/~hammett/articles/jta.html Its just evolving this implementation.
-- hammett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
