Patches item #583313, was opened at 2002-07-18 08:07
Message generated for change (Settings changed) made by topping
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=402706&aid=583313&group_id=31602
Category: ejbdoclet
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Andrew H. Barkley (andrew_barkley)
Assigned to: Brian Topping (topping)
Summary: Value object bidirectional relationships
Initial Comment:
I have a solution to the bidirectional relationships problem. The
fundamental problem is the recurrence of get*Value() calls
between arbitrary beans. This cycle can get very complex, so you
can't simply rely on a solution that fixes the problem between just
two beans.
The solution is to maintain a simple database-
like cache of the constructed value objects. The cache can be a
simple object, such as a Map. The Map would be keyed by entity
name to another Map, that would then be keyed by primary key to a
value object.
When a get*Value() method is called for an
entity bean, it will first try to retrieve its value object from the cache.
If
not present, the value object will be created and stored in the cache.
The value object will then
be returned.
The simplest
means of creating and maintaining this cache would is to add a
get*Value(Map) method for every existing get*Value() method.
The get*Value() method will simply instantiate the Map, and
delegate to
get*Value(Map). The get*Value(Map) method will
then perform mostly the same logic that is currently in get*Value(),
wrapped with the cache lookup. However, it must use the
get*Value(Map) methods of other beans, rather than the cache-
less versions. After the whole graph of value objects is created, the
cache will simply go out of scope and be garbage
collected.
This solution does not rely on maintaining state
within beans about value objects and is fully serializable, so it will
even be stable for remote relationships (remote
entities).
The disadvantage is in the added maintenance of
now a pair of getters for every value object.
----------------------------------------------------------------------
Comment By: Andrew H. Barkley (andrew_barkley)
Date: 2002-12-30 10:06
Message:
Logged In: YES
user_id=578528
This code was used quite extensively with great success. The issue of
staleness of value objects hasn't seemed to be a problem. After all, value
objects should be a snapshot in time of the entity graph. This snapshot should
model both the state and relationships of the entities. This patch does not
change the current model, but extends it to handle bidirectional and/or
cyclical relationships properly. The only case I can think of that would break
legacy code would be if the code relied somehow on having separate VO
instances representing the same entity in a given graph, but I can't come up
with a realistic design that relies on that.
I have not attempted to merge
this patch into the current release.
As for compile-time optionality...
An extra method is required for each entity to guarantee that this will work
correctly. It shouldn't be too difficult to prefer that method to the standard
VO
getter, and use it when available. That would be the most seemless way to drop
it in. Of course, if you want to have strict control over the style of VO
accessors
used, you could even augment the <valueobject/> element.
----------------------------------------------------------------------
Comment By: Brian Topping (topping)
Date: 2002-12-24 16:42
Message:
Logged In: YES
user_id=99236
Let me preface that I'd really like to find a solution to this
problem as well, so if we can get something that truly works
and is compile-time optional, I think it can be included. I
hadn't noticed that this had been assigned to me along the
way, so please excuse whatever delay in getting to this.
One of the concerns that I have about this is having a lot of
stale cached objects. I haven't looked at this code yet, but I
like the idea quite a bit.
Have you been using this code since back in July? Have any
thoughts on how it could be compile-time optionally
included? The PK problem in VO is rather fragile, and I'm
afraid of having a situation where the code cannot be turned
off by a legacy user that is having problems with it.
----------------------------------------------------------------------
Comment By: Andrew H. Barkley (andrew_barkley)
Date: 2002-07-19 18:08
Message:
Logged In: YES
user_id=578528
The patch has been updated to handle complex primary keys.
----------------------------------------------------------------------
Comment By: The Real John Barbee (eebrab)
Date: 2002-07-18 16:44
Message:
Logged In: YES
user_id=577266
hi,
i'm trying this patch and the generated code doesn't compile.
the patch assumes that we have the primkey-field set.
my proejct does not use primkey-field but the generated PK
classes instead.
e.g.
/**
* Id of this EJB
* @ejb:interface-method
* @ejb:persistent-field
* @ejb:value-object match="*"
* @ejb:pk
<<<<<<<<<<<<<<<<<<<<<<<<
* @ejb:pk-field
* @ejb:transaction type="SUPPORTS"
*/
can you tweak this patch to work?
if this ever gets committed, things will break.
----------------------------------------------------------------------
Comment By: Andrew H. Barkley (andrew_barkley)
Date: 2002-07-18 10:06
Message:
Logged In: YES
user_id=578528
The major annoyance to me about this implementation is the required
addition of the many get*Value(Map) methods to public interfaces. I
think it would make a lot of sense to put value-object-oriented methods in
the Util object (or one like it), so that these methods can be removed from
the public interface (package private?). Of course, that would make
dependencies between beans of different packages difficult.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=402706&aid=583313&group_id=31602
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
