It is not so much a tool as just part of the HibernateAssembler in LCDS 2.6. In 2.5.1 you used to have to specify something like:
<destination id="support5.Account">
<properties>
<source>flex.data.assemblers.HibernateAssembler</source>
<scope>application</scope>
<item-class>support5.Account</item-class>
<metadata>
<identity property="id"/>
<many-to-one property="consultant"
destination="support5.Consultant" lazy="true" />
<one-to-many property="accountContacts"
destination="support5.AccountContact" read-only="true" />
<one-to-many property="supportCases"
destination="support5.SupportCase" read-only="true" />
<one-to-many property="assets"
destination="support5.AccountAssetMatch" read-only="true"/>
</metadata>
</properties>
</destination>
for each destination. Now, you just need to specify:
<destination id="support5.Account">
<properties>
<source>flex.data.assemblers.HibernateAssembler</source>
<scope>application</scope>
<item-class>support5.Account</item-class>
</properties>
</destination>
It also used to be the case that you needed to specify all destinations used by
your flex app - even associated destinations. Now you just need to provide
that configuration for destinations you directly access from the client (i.e.
through a fill call or whatever). Any associated destinations needed by those
"top level" destinations are created for you automatically. When the
defaults for a particular association are not correct, you can specify just the
associations you want to override in the metadata tag. If you want to take
control entirely of the configuration for a particular destination, you just
specify the <identity> tags yourself and we revert back to the 2.5.1 mode.
Since the identity tag was required in 2.5.1 that also preserves the old
behavior configurations in 2.5.1 work properly in 2.6 without change.
Jeff
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of
uiowaflex
Sent: Friday, November 07, 2008 12:54 PM
To: [email protected]
Subject: [flexcoders] Re: Flex DataService problem: unexpected "unsubscribe"
and "release collection"
Jeff,
You mentioned that there is a tool that will automatically generate
data-management-config.xml from a hibernate configuration. Is this
tool available yet and if so where can I get it?
Thanks!
Andrew
The University of Iowa
--- In [email protected]<mailto:flexcoders%40yahoogroups.com>, "Jeff
Vroom" <[EMAIL PROTECTED]> wrote:
>
> Hi Greg,
>
>
>
> Sorry for the delay in my response.
>
>
>
> I think typically when you are using a managed association in LC DS you
> do not want to set any cascade operations like "merge" and "persist".
> This is especially true in 2.5.1 where cascade="save-update" (at least)
> caused problems when using managed associations.
>
>
>
> I am a little worried about the servlet filter which keeps the session
> open. I think for remote object that approach might work fine but for
> data management, it is opening and closing its own session so not sure
> how that would interact with your global session.
>
>
>
> One thing I noticed is that you have "parent" properties with
> lazy="false". That can be scary because it can end up pulling in a
> lot more of the model than you intend through that association. I
> usually recommend that parent always have lazy="true".
>
>
>
> Also, just to let you know the 2.6 beta is on labs.adobe.com and so you
> might want to give that a shot. It will generate the metadata section
> of the data-management-config.xml automatically from the hibernate
> configuration so that makes it easier to get started.
>
>
>
> In terms of the cascade settings, when you declare a managed association
> in LC DS for an association in hibernate, normally we do not require any
> cascade options enabled. I would like the assembler to not care if you
> do but unfortunately in 2.5.1 there is a bug when you set save-update
> (at least). I do have a fix for that problem but it did not make it
> into beta 2. If you do get on 2.6 and would like to try out the fix,
> drop me an email at [EMAIL PROTECTED] and I'll send you the jar.
>
>
>
> Jeff
>
>
>
> ________________________________
>
> From: [email protected]<mailto:flexcoders%40yahoogroups.com>
> [mailto:[email protected]<mailto:flexcoders%40yahoogroups.com>] On
> Behalf Of gordon_greg
> Sent: Wednesday, April 09, 2008 9:00 AM
> To: [email protected]<mailto:flexcoders%40yahoogroups.com>
> Subject: [flexcoders] Re: Flex DataService problem: unexpected
> "unsubscribe" and "release collection"
>
>
>
> Again, many thanks as this thread is shedding much needed light on my
> world.
>
> I'm planning on spending my day working through my Hibernate/LCDS
> settings, focusing on defining all bi-directional relationships and
> Hibernate cascading...
>
> In reviewing this thread I notice in your last response a bit of an
> inconsistency from a previous response:
>
> on April 8 you mentioned:
>
> Hibernate has an option called cascade="save-update".... This
> option is always true by default with LC DS.
>
> This was in reference to adding a new item to a managed collection that
> is a bi-directional association.
>
> However, last night you also mentioned:
>
> With hierarchical values you need to use cascade="save-update" since
> then it becomes the responsibility of the parent to save the child.
> Unfortunately in 2.5.1 save-update can break a managed association so
> you use save-update with no association and don't use it when you do
> have one.
>
> My current understanding is that I should define all bi-directional
> assocations in LCDS the same as I have in Hibernate, since I do NOT want
> them treated as Hierarchical values, and as such I'm guessing from your
> last post that I should NOT declare cascade="save-update" in the parent
> classes, is this correct?
>
> Perhaps we should just use a concrete example and get it over with ;)
>
> Bear with me...
>
> Let's say we want to represent a tree of items and groups, and for
> simplicity we'll say that an item will only belong to a single group, a
> group can have subgroups, and that we want to yield cascading deletes
> when deleting a group. (And finally that we want all collections
> lazy-loaded!)
>
> Our SQL tables look like:
>
> Group
> - id:integer
> - parent_id:integer
> - name:varchar(25)
>
> Item
> - id:integer
> - group_id:integer
> - name:varchar(25)
>
> Our annotated Hibernate classes:
>
> ------------------------------ START: my.models.Group.java
> ------------------------------
>
> @Entity
>
> @Table( name="Group")
>
> public class Group {
>
>
>
> private Integer id;
>
> private String name;
>
> private Group parent;
>
> private List<Group> subGroups;
>
> private List<Item> items;
>
>
>
> @Id
>
> @GeneratedValue(strategy=GenerationType.AUTO)
>
> public Integer getId(){ return id; }
>
> public void setId(Integer id) {
>
> this.id = id;
>
> // due to problems with LCDS passing up 0's instead of nulls, I
> detect this on my own...
>
> if (id != null && id.intValue() == 0) this.id = null;
>
> }
>
>
>
> public String getName(){ return name; }
>
> public void setName(String name){ this.name = name; }
>
>
>
> @ManyToOne()
>
> @JoinColumn(name="parent_id", nullable=true, insertable=true,
> updatable=true)
>
> public Group getParent() { return parent; }
>
> public void setParent(Group parent) { this.parent = parent; }
>
>
>
> @OneToMany(mappedBy="parent", fetch = {FetchType.LAZY},
> cascade = {CascadeType.PERSIST,
> CascadeType.MERGE})
>
> @Cascade({org.hibernate.annotations.CascadeType.DELETE_ORPHAN})
>
> public List<Group> getSubGroups() { return subGroups; }
>
> public void setSubGroups(List<Group> subGroups) { this.subGroups =
> subGroups; }
>
>
>
> @OneToMany(mappedBy="group", fetch = {FetchType.LAZY},
> cascade = {CascadeType.PERSIST,
> CascadeType.MERGE})
>
> @Cascade({org.hibernate.annotations.CascadeType.DELETE_ORPHAN})
>
> public List<Item> getItems() { return items; }
>
> public void setItems(List<Item> items) { this.items = items; }
>
> }
>
> ------------------------------ END: my.models.Group.java
> ------------------------------
>
> ------------------------------ START: my.models.Item.java
> ------------------------------
>
> @Entity
>
> @Table( name="Item")
>
> public class Item {
>
>
>
> private Integer id;
>
> private String name;
>
> private Group group;
>
>
>
> @Id
>
> @GeneratedValue(strategy=GenerationType.AUTO)
>
> public Integer getId(){ return id; }
>
> public void setId(Integer id) {
>
> this.id = id;
>
> // due to problems with LCDS passing up 0's instead of nulls, I
> detect this on my own...
>
> if (id != null && id.intValue() == 0) this.id = null;
>
> }
>
>
>
> public String getName(){ return name; }
>
> public void setName(String name){ this.name = name; }
>
>
>
> @ManyToOne()
>
> @JoinColumn(name="group_id", nullable=true, insertable=true,
> updatable=true)
>
> public Group getGroup() { return group; }
>
> public void setGroup(Group group) { this.group = group; }
>
> }
>
> ------------------------------ END: my.models.Item.java
> ------------------------------
>
> And finally our DataService destinations:
>
> ------------------------------ START destinations
> ------------------------------
> <destination id="spring.group">
>
> <adapter ref="java-dao"/>
>
> <properties>
>
> <scope>application</scope>
>
> <source>groupAssemblerBean</source>
>
> <factory>spring</factory>
>
> <item-class>my.models.Group</item-class>
>
> <metadata>
>
> <identity property="id" undefined-value="0"/>
>
> <many-to-one property="parent"
> destination="spring.group" lazy="false"/>
>
> <one-to-many property="subGroups"
> destination="spring.group" lazy="true"/>
>
> <one-to-many property="items" destination="spring.item"
> lazy="true"/>
>
> </metadata>
>
> <network>
>
>
> <subscription-timeout-minutes>0</subscription-timeout-minutes>
>
> <reconnect fetch="INSTANCE"/>
>
> </network>
>
> </properties>
>
> </destination>
>
>
>
> <destination id="spring.item">
>
> <adapter ref="java-dao"/>
>
> <properties>
>
> <scope>application</scope>
>
> <source>groupAssemblerBean</source>
>
> <factory>spring</factory>
>
> <item-class>my.models.Group</item-class>
>
> <metadata>
>
> <identity property="id" undefined-value="0"/>
>
> <many-to-one property="group" destination="spring.group"
> lazy="false"/>
>
> </metadata>
>
> <network>
>
>
> <subscription-timeout-minutes>0</subscription-timeout-minutes>
>
> <reconnect fetch="INSTANCE"/>
>
> </network>
>
> </properties>
>
> </destination>
>
> ------------------------------ END destinations
> ------------------------------
>
> Now, notice that I'm using Spring as well as Hibernate, so I've followed
> the examples online to use the Spring factory, and because I've got lazy
> loaded collections and need to force the Hibernate session to stay open,
> I've routed LCDS to have all traffic flow through a single "spring"
> servlet, and that servlet in turn has all of the usual "flex" servlets
> defined as controllers, and I'm using Spring's
> openSessionInViewInterceptor to keep the Hibernate session open.
>
> I realize this may create some differences that actually matter to LCDS,
> but what I'm looking for in this post is whether I have the right idea
> in how I've configured the associations between Flex and Hibernate, and
> specifically if the Cascade values look right for interacting with LCDS.
>
> I also realize that since I'm not specifically declaring the use of the
> HibernateAssembly in my destinations, and because I'm using annotations,
> I'm guessing it's possible that LCDS is not able to "read" the Hibernate
> configuration properly, although I also have no idea whether this really
> matters. I also don't know that it matters that I'm not specifying a
> <hibernate-entity> element...
>
> Anyway, if you've read this much I surely appreciate you taking your
> time on this!
>
> Many thanks,
>
> Greg
>
<<inline: image001.jpg>>
<<inline: image002.jpg>>
