You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@juddi.apache.org by Jeff Faath <jf...@apache.org> on 2008/09/16 03:04:24 UTC
Question regarding persistence layer: UddiEntity
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
Re: Question regarding persistence layer: UddiEntity
Posted by Kurt T Stam <ku...@gmail.com>.
Sounds good to me. --Kurt
Jeff Faath wrote:
> The subscription api uses the operationalInfo structure. I know this
> because it's one of the functions I added to the current version of juddi
> for my company. The operationalInfo structure does contain a record of
> every "uddi entity" in the form of the "entityKey" but it is really a
> OneToOne foreign key relationship...not a parent.
>
> If there's no pressing need that can be seen for the current UddiEntity, I'm
> going to remove it as a separate entity. I am actually thinking I'm going
> to use it as a super class for all the aforementioned "uddi entities". That
> way, I can continue to call persist with a single method signature.
> Additionally, there are fields that are common to all these entities
> ("lastUpdated" comes to mind). I'll use the table-per-subclass inheritance
> pattern when annotating with JPA.
>
> If anyone has any other suggestions, please let me know. I'll probably
> start working on this later today or tomorrow.
>
> Regards,
>
> Jeff
>
> -----Original Message-----
> From: Tom Cunningham [mailto:tcunning@redhat.com]
> Sent: Tuesday, September 16, 2008 11:25 AM
> To: juddi-dev@ws.apache.org
> Subject: Re: Question regarding persistence layer: UddiEntity
>
>
>
> 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:kurt.stam@gmail.com]
>> *Sent:* Tuesday, September 16, 2008 8:55 AM
>> *To:* juddi-dev@ws.apache.org
>> *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:kurt.stam@gmail.com]
>> *Sent:* Monday, September 15, 2008 9:36 PM
>> *To:* juddi-dev@ws.apache.org <ma...@ws.apache.org>
>> *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: juddi-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: juddi-dev-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: juddi-dev-help@ws.apache.org
>
>
>
RE: Question regarding persistence layer: UddiEntity
Posted by Jeff Faath <jf...@apache.org>.
The subscription api uses the operationalInfo structure. I know this
because it's one of the functions I added to the current version of juddi
for my company. The operationalInfo structure does contain a record of
every "uddi entity" in the form of the "entityKey" but it is really a
OneToOne foreign key relationship...not a parent.
If there's no pressing need that can be seen for the current UddiEntity, I'm
going to remove it as a separate entity. I am actually thinking I'm going
to use it as a super class for all the aforementioned "uddi entities". That
way, I can continue to call persist with a single method signature.
Additionally, there are fields that are common to all these entities
("lastUpdated" comes to mind). I'll use the table-per-subclass inheritance
pattern when annotating with JPA.
If anyone has any other suggestions, please let me know. I'll probably
start working on this later today or tomorrow.
Regards,
Jeff
-----Original Message-----
From: Tom Cunningham [mailto:tcunning@redhat.com]
Sent: Tuesday, September 16, 2008 11:25 AM
To: juddi-dev@ws.apache.org
Subject: Re: Question regarding persistence layer: UddiEntity
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:kurt.stam@gmail.com]
> *Sent:* Tuesday, September 16, 2008 8:55 AM
> *To:* juddi-dev@ws.apache.org
> *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:kurt.stam@gmail.com]
> *Sent:* Monday, September 15, 2008 9:36 PM
> *To:* juddi-dev@ws.apache.org <ma...@ws.apache.org>
> *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: juddi-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-dev-help@ws.apache.org
Re: Question regarding persistence layer: UddiEntity
Posted by Tom Cunningham <tc...@redhat.com>.
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:kurt.stam@gmail.com]
> *Sent:* Tuesday, September 16, 2008 8:55 AM
> *To:* juddi-dev@ws.apache.org
> *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:kurt.stam@gmail.com]
> *Sent:* Monday, September 15, 2008 9:36 PM
> *To:* juddi-dev@ws.apache.org <ma...@ws.apache.org>
> *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: juddi-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-dev-help@ws.apache.org
RE: Question regarding persistence layer: UddiEntity
Posted by Jeff Faath <jf...@apache.org>.
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:kurt.stam@gmail.com]
Sent: Tuesday, September 16, 2008 8:55 AM
To: juddi-dev@ws.apache.org
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:kurt.stam@gmail.com]
Sent: Monday, September 15, 2008 9:36 PM
To: juddi-dev@ws.apache.org
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
Re: Question regarding persistence layer: UddiEntity
Posted by Kurt T Stam <ku...@gmail.com>.
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:kurt.stam@gmail.com]
> *Sent:* Monday, September 15, 2008 9:36 PM
> *To:* juddi-dev@ws.apache.org
> *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
>
>
>
>
>
RE: Question regarding persistence layer: UddiEntity
Posted by Jeff Faath <jf...@apache.org>.
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:kurt.stam@gmail.com]
Sent: Monday, September 15, 2008 9:36 PM
To: juddi-dev@ws.apache.org
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
Re: Question regarding persistence layer: UddiEntity
Posted by Kurt T Stam <ku...@gmail.com>.
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
>
>
>