Heyas,
I've been getting my feet wet with VO and CMR lately, very nice!
As I was pulling stuff together for this app that has been consuming my life
lately, I started seeing that composition was what I wanted for one of my
relationships. My ejbCreate methods have some mostly-baked (but
transactionally secure) PK ID pooling going on, so a call to
someEntity.create() gives the object with the next sequential ID for a
particular JVM and it's pool block. (The code is generated through
entitycmp-custom.xdt in the build, and I'm happy to share it with anyone
interested...)
So what this leaves is an autonumbering composition by creating a related VO
and calling addSthRelated() on the composed parent VO. When the parent VO is
sent to setSthValue on the entity, everything works smoothly.
But the problem is, there is really no way to get a reference to the newly
generated VO that was added to the *parent* VO. I committed (and later
reversed) some changes last night to return the PK for the newly created
child VO from VO.addSth(). I backed them out because there was some problems
with BMP that I'm not ready to look at yet. But with that code, since the
add returns the PK, it's possible to absolutely reference the created child
relation in the parent VO. The use case of this could be one parent with an
intentional insertion of two similar items in the relation. A search on a
non-unique field would return multiple records, which is bad. We just want
the last record, even if the identifying fields are otherwise the same.
The design of VO CMR is (as best as I can tell) such that as long as the PK
is correct, the fact that a related object did not clone from the parent VO
hash does not matter. In other words, if I want to make a change to a
related child VO, I can simply call updateSth() on the parent VO and the
related entity with the corresponding VO will be updated when the parent is
flushed. So with the PK, I could go out to the related entities and
findByPrimaryKey, get the VO, then update the record locally.
But making another round-trip through the session and entity to get a copy of
the related VO is wasteful, especially since we have it on the client in the
VO CMR hashes already. Alternately, with the PK and the parent VO CMR
hashes, one could find the record that was added through sequential search.
But it seems that it would be faster (and cleaner from the client
perspective) to turn the Collections into a Map, keyed by PK.
So I've cooked some changes to valueobject.xdt such that the type attribute
of @ejb:value-object can be set to java.util.Map. The effect is that the VO
will keep the CMR relations in a Map, keyed by PK. Everything does what it
should for the beans that use "@ejb:bean primkey-field=...", I haven't tested
for PKs generated by <entitypk/> yet.
With all this, the client code for using composition is greatly reduced to
something like:
SthParentValue sv = ....
SthRelatedValue relation = new SthRelatedValue("foo", "bar"...);
SthRelatedPK pk = sv.addSthRelated(relation);
relation = sv.getSthRelated(pk);
So the question is "is any of this useful"? After pulling it all together,
I'm kind of wondering whether I've reinvented the wheel on something that
people already have better solutions for or whether this is a solution to
something that's been a PITA for a while and I ought to go ahead with
cleaning it up and checking it in with some docs. It may not be as relevant
when considered outside the realm of autoincrementing PKs, so I'm also
interested if that's something people don't do much of.
If it turns out that this is useful code, it's a pretty low-risk change
because the selector on the tag that triggers all the generation
(@ejb:value-object ... type="java.util.Map") is new.
Feedback appreciated,
-b
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
