I'm fine with removing UddiEntity, but we probably do need the
uber-parent idea for some of the features (subscriptions for example -
see section C.2.2). Are we able to handle this through the persistence
layer instead?
Jeff Faath wrote:
The cascade option already exists in the relationship. However, it is
a OneToMany (ie. UddiEntity has a bunch of collections). I wasn’t sure
why UddiEntity was structured like this which indicates I might not be
using it correctly. I can’t find UddiEntity anywhere in the spec either.
*From:* Kurt T Stam [mailto:[EMAIL PROTECTED]
*Sent:* Tuesday, September 16, 2008 8:55 AM
*To:* [email protected]
*Subject:* Re: Question regarding persistence layer: UddiEntity
We may be saying the same thing, but I mean adding an annotation
saying something like:
@OneToOne(cascade=CascadeType.ALL)
on the child or parent entity.
--K
Jeff Faath wrote:
No, that’s what I want to avoid having to do…manually cascading the
saves to the child UDDI objects. If the UddiEntity reference didn’t
exist, I could literally call the “persist” on the top level
BusinessEntity and every child entity – services, bindings, etc –
would save automatically.
*From:* Kurt T Stam [mailto:[EMAIL PROTECTED]
*Sent:* Monday, September 15, 2008 9:36 PM
*To:* [email protected] <mailto:[email protected]>
*Subject:* Re: Question regarding persistence layer: UddiEntity
Jeff are you cascading the saves into this UDDIEntity object as well?
Jeff Faath wrote:
Kurt, Tom,
Have a question regarding the UddiEntity entity in the persistence
layer. It appears its function is to be the uber-parent of all “uddi
entities” - the principles being BusinessEntity, BusinessService,
BindingTemplate, and Tmodel.
http://uddi.org/pubs/uddi-v3.0.2-20041019.htm#_Toc85908007
So, each one of these principle entities in the domain model contains
a reference to its own UddiEntity. In the DB schema, this simply
translates to the entity key in the uddi_entity table, and as a
result, each entity’s primary key has a foreign key constraint tied to
this table.
My question is: I’m curious as to the usefulness of this structure.
At first, I thought it fit well, because it allowed me to create a
persist method with a single signature (ie. persistEntity(UddiEntity
ue)). However, as I’m building out more of the logic - particularly as
I’m starting to incorporate the built-in UDDI hierarchies - it is
causing problems. It is interfering with the natural cascading saves
that can exist in the UDDI hierarchy. Because each “entity” has this
reference, I receive this persistence error, “object references an
unsaved transient instance…”, when trying to save an entity with child
“uddi entities” (I’m using a very simple example of one BusinessEntity
with one BusinessService – and the BusinessService has no child entities).
There might be a use for this structure that I’m not seeing. But as it
stands with the publishing API, it clashes with the ability to perform
cascading saves. I can work with it if need be, but I’d have to write
code that saves each “uddi entity” separately, even when the entity is
provided as a child of a parent entity.
-Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
