Hi Douglas,

I misspoke on one of my recommendations:

> One more thing is that because you are using a "complex"
> object type as an identity property, your FilmActor.as
> class will need a function like:
> public function toString():String
> {
> return actorId + ":" + filmId
> }

I meant to say add this to the FilmActorId.as class.  Sorry about that! 

> Two more questions:

> 1. This would be so much easier if I had a working example to work
from. 
> I haven't found any examples that use the 'managed associations' 
> approach - with one-to-many or many-to-many relationships. Jeff, do
you 
> know of any? Does anyone?

Let me see if I can dig something up.  We have a few applications folks
built internally here that use hibernate with managed associations.  It
may take a bit of cleaning up to get it so they can be given out. 

> 2. Victor Rubba has been kind enough to show me some code that he has 
> that implements a many-to-many relationship with a link table. His
link 
> table has a numeric id column, which allows his code to avoid the
whole 
> "complex id" issue. Thus his destination config avoids 'composite-id'.

> Everything is much simpler. :-) (!) But we're wondering if this
approach 
> is "correct", or if it's more correct to have a link table that only 
> contains IDs from the linked tables, i.e. a composite ID.

Both of those approaches work and so are correct in a certain sense.
Probably most DBAs would prefer the link table which only has the ids
from the linked tables since that extra id column is not strictly
necessary.  Note that FDMS supports Java/Actionscript objects which have
more than one id property but I think hibernate requires that all id
columns are stored in the same property in Java.  I am not sure about
that...

Jeff

-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED] On
Behalf Of Douglas McCarroll
Sent: Monday, December 04, 2006 6:00 PM
To: [email protected]
Subject: Re: [flexcoders] many-to-many managed association in Hibernate
destination

Hi Jeff,

 > Ok, so I think I see the problem then...

Thanks for the response. I'm having some trouble applying this to my 
particular case and would like to check a bit to make sure that we're on

the same page.


Here's my question:



If I run HibernateTools on a many-to-many table relationship with a link

table - as shown here: 
http://www.brightworks.com/technology/tech_questions/hibernate_lazy_asso
ciations/index.html 
- it creates a Java file like this:



FilmActor.java

package com.brightworks.apps.dvd_store;

import java.util.Date;

public class FilmActor {

private FilmActorId id;
private Film film;
private Actor actor;
private Date lastUpdate;

public FilmActor() {
}

public FilmActor(FilmActorId id, Film film, Actor actor, Date
lastUpdate) {
this.id = id;
this.film = film;
this.actor = actor;
this.lastUpdate = lastUpdate;
}

public FilmActorId getId() {
return this.id;
}

public void setId(FilmActorId id) {
this.id = id;
}

public Film getFilm() {
return this.film;
}

public void setFilm(Film film) {
this.film = film;
}

public Actor getActor() {
return this.actor;
}

public void setActor(Actor actor) {
this.actor = actor;
}

public Date getLastUpdate() {
return this.lastUpdate;
}

public void setLastUpdate(Date lastUpdate) {
this.lastUpdate = lastUpdate;
}

}




The link table uses actor_id and film_id columns to link to the other 
two tables.

But a FilmActor.java instance has:

a) References to the Actor and Film instances that it is linking
b) An instance of FilmActorId.java. This class obviously acts as the 
"ID" for FilmActor.java and contains ActorId and FilmId values. It's 
described in the mapping file like this:


<composite-id
name="id"
class="com.brightworks.apps.dvd_store.FilmActorId">
<key-property
name="actorId"
type="short">
<column name="actor_id" />
</key-property>
<key-property
name="filmId"
type="short">
<column name="film_id" />
</key-property>
</composite-id>



You wrote:

 > One more thing is that because you are using a "complex"
 > object type as an identity property, your FilmActor.as
 > class will need a function like:

When you say "complex object type" I assume that you're referring
to FilmActorId. Am I correct so far?

But I run into a problem here:

 > public function toString():String
 > {
 > return actorId + ":" + filmId
 > }


My FilmActor.as looks like this:


package com.brightworks.apps.dvd_store.vo
{
[Managed]
[RemoteClass(alias="com.brightworks.apps.dvd_store.FilmActor")]

public class FilmActor
{
public function FilmActor() {}

public var filmActorId:FilmActorId;
public var film:Film;
public var actor:Actor;
public var lastUpdate:Date;
}
}


I wrote it to simply reflect FilmActor.java's structure.

It has no actorId or filmId, so I can't do "return actorId + ":" +
filmId"

I could add these properties, but I don't see how/why they'd get int 
values from FilmActor.java. Would FDMS or Hibernate know enough to pull 
them out of the FilmActor.java's "complex ID"?

 > you could potentially implement the Film/Actors relationship
 > without an intermediate FilmActors class - both hibernate
 > and FDMS will support that and since you do not have any
 > additional properties in the mapping table, it is pretty
 > common to avoid an extra type.

I also have questions about this but I think I'll hold off for now. Best

to get the other case working first, I think. Frankly, I don't know 
Hibernate very well. My current learning strategy is to assume that 
HibernateTools is generating reasonably correct code, and to focus on 
learning how to implement the FDMS/H8 connection. Later, I'll be 
learning more about Hibernate.

Two more questions:

1. This would be so much easier if I had a working example to work from.

I haven't found any examples that use the 'managed associations' 
approach - with one-to-many or many-to-many relationships. Jeff, do you 
know of any? Does anyone?

2. Victor Rubba has been kind enough to show me some code that he has 
that implements a many-to-many relationship with a link table. His link 
table has a numeric id column, which allows his code to avoid the whole 
"complex id" issue. Thus his destination config avoids 'composite-id'. 
Everything is much simpler. :-) (!) But we're wondering if this approach

is "correct", or if it's more correct to have a link table that only 
contains IDs from the linked tables, i.e. a composite ID.


Thanks,

Douglas


Jeff Vroom wrote:
>
> Hi Douglas,
>
> Ok, so I think I see the problem then - my apologies for not seeing it

> sooner. The FDMS destination does not have a destination for the 
> "filmActors" type. Also, the property: "Actor.filmActors" has this 
> association tag:
>
> <many-to-many
>
> property="filmActors"
>
> destination="film.hibernate"
>
> lazy="true" />
>
> it should instead refer to the new filmActors.hibernate destination 
> you would add. This type would have its identity property with the 
> name "id" and would have lazy one-to-one association properties both 
> for "film" and "actor" which refer to the destinations 
> "film.hibernate" and "actor.hibernate". One more thing is that because

> you are using a "complex" object type as an identity property, your 
> FilmActor.as class will need a function like:
>
> public function toString():String
>
> {
>
> return actorId + ":" + filmId
>
> }
>
> This is a requirement for complex object identity properties in FDMS 
> (due to the fact that there is no Hashtable like class in ActionScript

> which uses equals/hashCode methods, we use a string key generated from

> the toString values of all identity properties to keep track of 
> instances on the client).
>
> I think the hibernate assembler is missing an error test for the case 
> where the type of the referenced entity does not match the 
> destination's entity type. I'll fix that right away as that would have

> saved you a lot of time. Instead, it is looking for a "filmId" 
> property on the FilmActor type and is getting back null (it should 
> also print an error instead here).
>
> One other thing I'll mention as an aside is that you could potentially

> implement the Film/Actors relationship without an intermediate 
> FilmActors class - both hibernate and FDMS will support that and since

> you do not have any additional properties in the mapping table, it is 
> pretty common to avoid an extra type.
>
> You are right though that this fix will not greatly improve the 
> performance. We are still going to need to do a query for each actor 
> to retrieve the filmActors properties. It will be a little faster than

> today because it won't need to join in the Film table because of the 
> intermediate mapping object.
>
> Jeff
>
>
------------------------------------------------------------------------
>
> *From:* [email protected] [mailto:[EMAIL PROTECTED]

> *On Behalf Of *Douglas McCarroll
> *Sent:* Thursday, November 30, 2006 5:39 PM
> *To:* [email protected]
> *Subject:* Re: [flexcoders] many-to-many managed association in 
> Hibernate destination
>
> Hi Jeff,
>
> A couple more thoughts...
>
> It's worth noting that I don't get the error when I use the
hierarchical
> values approach without lazy loading, and get my films info from my
> actor objects.
>
> > Thanks for this info. The performance problem is most likely due to
the
> > fact that FDMS is fetching the list of films for each actor... this
is
> > the lazy loading issue we have currently that I mentioned in a
previous
> > post. If we were to follow the hibernate model more closely, we'd
send
> > "actor" instances to the client without having populated the list of
> > films for each actor at all. The first "get" call made on the films
> > property for a given actor would then go back to the server and
fetch
> > them. As it is now, we'll do one query to retrieve the list of
actors,
> > then a query for each actor to get its list of films. For a large
DB,
> > this is a lot of queries to do.
>
> > This is a pretty high priority feature request. For now, the
workaround
> > would be to modify your domain model so there is an intermediate
object
> > but that is awkward when you are generating everything from the
simple
> > schema.
>
> I'm not sure that I understand this. I believe that I have "an
> intermediate object" - filmActor.java and filmActor.as.
>
> Are you suggesting that I use that object - or rather those objects -
as
> a way of finding out what filmIds are related to an actorId? I.e. that
I
> load them from their own destination? I'm tired so if this isn't
clear,
> don't worry about it. :-)
>
> Do I understand correctly that until we get the fix lazy loading isn't
> necessarily going to solve any performance problems?
>
> Douglas
>
> Jeff Vroom wrote:
> >
> > Thanks for this info. The performance problem is most likely due to
the
> > fact that FDMS is fetching the list of films for each actor... this
is
> > the lazy loading issue we have currently that I mentioned in a
previous
> > post. If we were to follow the hibernate model more closely, we'd
send
> > "actor" instances to the client without having populated the list of
> > films for each actor at all. The first "get" call made on the films
> > property for a given actor would then go back to the server and
fetch
> > them. As it is now, we'll do one query to retrieve the list of
actors,
> > then a query for each actor to get its list of films. For a large
DB,
> > this is a lot of queries to do.
> >
> > This is a pretty high priority feature request. For now, the
workaround
> > would be to modify your domain model so there is an intermediate
object
> > but that is awkward when you are generating everything from the
simple
> > schema.
> >
> > As to why it is not working, from the output, the "filmId" of each
Film
> > object is getting sent to the client as a "null" value. I am not
sure
> > why... I can't tell if it is retrieving the values from the database
as
> > null or if FDMS is just not getting the values from the objects
> > properly. It could have something to do with the "short" data type -
I
> > do not think we've tried id properties as short values so maybe
> > something is getting messed up because of that? It might be worth
> > changing that to an int if that is an easy test to run.
> >
> > I will try to get a chance to look at this more tomorrow.
> >
> > Jeff
> >
> > -----Original Message-----
> > From: [email protected] 
> <mailto:flexcoders%40yahoogroups.com> 
> <mailto:flexcoders%40yahoogroups.com>
> > [mailto:[email protected]
<mailto:flexcoders%40yahoogroups.com>
> > <mailto:flexcoders%40yahoogroups.com>] On
> > Behalf Of Douglas McCarroll
> > Sent: Wednesday, November 29, 2006 11:26 AM
> > To: [email protected] <mailto:flexcoders%40yahoogroups.com>

> <mailto:flexcoders%40yahoogroups.com>
> > Subject: Re: [flexcoders] many-to-many managed association in
Hibernate
> > destination
> >
> > Jeff Vroom wrote:
> >
> > > 4) If you turn on debug logging in the server for
> > > the "Endpoint.*" logging category, you'll see the
> > > object graph which is sent to the client after
> > > your fill. I am curious if the time is being
> > > spent loading the data from the database or
> > > sending data to the client, or a combination of
> > > both.
> >
> > Okay, I've figured out how to do this part. Results here:
> >
> >
http://www.brightworks.com/technology/tech_questions/hibernate_lazy_asso

>
<http://www.brightworks.com/technology/tech_questions/hibernate_lazy_ass
o> 
>
> >
<http://www.brightworks.com/technology/tech_questions/hibernate_lazy_ass
o 
>
<http://www.brightworks.com/technology/tech_questions/hibernate_lazy_ass
o>>
> > ciations/debug_log_01.txt
> >
> > > If you can also turn on debug logging of the SQL
> > > that hibernate is using that would help figure out
> > > if we are just fetching too many objects or what.
> >
> > It looks as though I do this by adding a line to
> > HibernateManager.java...
> >
> > public void createSessionFactory(Configuration hibernateConfig,
> > boolean useTransactions) throws ExceptionInInitializerError
> > {
> > try
> > {
> >
> > New Line -> hibernateConfig.setProperty("hibernate.show_sql",
"true")
> >
> > sessionFactory = hibernateConfig.buildSessionFactory();
> >
> > Yes?
> >
> > BTW, in case someone finds this someday with Google, here are some
> > resources:
> >
> > FDS Logging:
> >
> >
http://livedocs.macromedia.com/flex/2/docs/wwhelp/wwhimpl/common/html/ww

>
<http://livedocs.macromedia.com/flex/2/docs/wwhelp/wwhimpl/common/html/w
w> 
>
> >
<http://livedocs.macromedia.com/flex/2/docs/wwhelp/wwhimpl/common/html/w
w 
>
<http://livedocs.macromedia.com/flex/2/docs/wwhelp/wwhimpl/common/html/w
w>>
> > help.htm?context=LiveDocs_Parts&file=00001112.html
> >
> >
http://weblogs.macromedia.com/dharfleet/archives/2006/08/debugging_flex.

>
<http://weblogs.macromedia.com/dharfleet/archives/2006/08/debugging_flex
.> 
>
> >
<http://weblogs.macromedia.com/dharfleet/archives/2006/08/debugging_flex
. 
>
<http://weblogs.macromedia.com/dharfleet/archives/2006/08/debugging_flex
.>>
> > cfm
> >
> > http://tech.groups.yahoo.com/group/flexcoders/message/56192 
> <http://tech.groups.yahoo.com/group/flexcoders/message/56192>
> > <http://tech.groups.yahoo.com/group/flexcoders/message/56192 
> <http://tech.groups.yahoo.com/group/flexcoders/message/56192>>
> >
> > Hibernate Logging:
> >
> > http://www.javalobby.org/java/forums/t44119.html 
> <http://www.javalobby.org/java/forums/t44119.html>
> > <http://www.javalobby.org/java/forums/t44119.html 
> <http://www.javalobby.org/java/forums/t44119.html>>
> >
> > --
> > Flexcoders Mailing List
> > FAQ:
http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt 
> <http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt>
> > <http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt 
> <http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt>>
> > Search Archives:
> > http://www.mail-archive.com/flexcoders%40yahoogroups.com 
> <http://www.mail-archive.com/flexcoders%40yahoogroups.com>
> > <http://www.mail-archive.com/flexcoders%40yahoogroups.com 
> <http://www.mail-archive.com/flexcoders%40yahoogroups.com>>
> > Yahoo! Groups Links
> >
> >
>
>  



--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives:
http://www.mail-archive.com/flexcoders%40yahoogroups.com 
Yahoo! Groups Links



Reply via email to