Here are a couple of features that JPA has that can be very useful:
1. More powerful query language. The tradeoff is that HQL is not
type-safe like Mapper's findXXX methods, so you need to test your query
syntax to make sure it returns what you want. Granted, you can use SQL
directly in Mapper, but it's tied directly to the DB while HQL allows you to
abstract away some of the smaller details, particularly with join
associations. However, HQL does allow you to easily
1. Do flexible joins between large graphs of objects
2. Select scalar values (i.e. "select distinct player.age from
TeamMember player where ...")
3. Prefetch otherwise lazily loaded properties ("select player from
TeamMember left join fetch player.coach")
2. IMHO, better definition of associations between classes.
HasManyThrough works well for a subset of usages, but it:
1. Can't be treated as a real, live collection (no updates, no
cascades)
2. Only runs once (it's lazy). Given the duration of a web request
cycle this would usually not be a big deal unless you have a
high number of
concurrent users operating on the same data
3. Doesn't map well to many-to-many relationships; you have to build
your own binding entity to represent the join table
3. JPA has a number of implementations available for an intermediate
cache to improve performance
4. JPA supports locking of objects for read and write
That's what I can come up with off the top of my head. Having SEAM generate
the classes for you is also nice, although I'm sure a similar tool could be
written for Mapper. Now, as for SEAM's (ab)use of the entity manager (I'm
assuming that's what you mean by transaction manager), I'm not so sure that
it's actually keeping the EM open across the entire "conversation", but
rather providing an interface that makes it appear that it is. I saw Gavin
King here give a presentation on SEAM a few years ago and it sounded like
they were doing some magic behind the scenes to keep everything coherent. I
don't really know enough about it to argue for or against it, but generally
the idea is that by holding a transaction across the scope of an entire
conversation you can treat a series of forms/pages as an atomic unit of
work. I'm pretty sure Mapper doesn't have anything comparable, and Mapper's
concept of lazy loading isn't tied to having an open EM like it is in JPA.
That means that if something in Mapper is going to be lazily loaded, it'll
work no matter what.
Derek
On Fri, Dec 5, 2008 at 6:24 PM, philip <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Why should I use JPA as vs using Liftwebs built in database mappers.
> Lets say I build a 100 table mysql database, I'm mostly doing forms,
> user input, tables out.
> Is there something unattractive about using Liftwebs built in mapper?
> I don't like the name MetaMegaProtoUser, but thats just aesthetics.
>
> Currently I can generate lots of Java JPA classes from database using
> SEAMs generation ant script, my thought was then to use those Java
> classes and convert them over to Scala JPA as in the example project.
> However I don't know why to do this as opposed to using Liftweb's
> mapper.
>
> I'm also worried about something and not sure if I should be worried
> about it. JBoss SEAM has this concept of conversational state and it
> can keep the JPA transaction manager open from one page to another
> page, through use of the session. SEAM claims this is a good idea and
> we shouldn't be closing the transaction manager on each call. Also it
> can keep a transaction open for a long time through page views.
> However, I don't see why or when I would need to do a transaction with
> multiple page views involved in it. I mean, even large websites like
> facebook, I doubt they do this - they use PHP. Why not just do the
> transaction in one call?
>
> SEAM also has this concept of avoiding the Hibernate
> LazyInitializationException, so if your navigating down some objects
> relations, it will load the lazy relations as you navigate down. So
> you don't need to re-query the database, because of the transaction
> manager being open between pages, it will load the Hibernate objects
> that are lazy loaded as you navigate a O-R structure.
> Of course this sounds attractive in regards to SEAM.
> What if I navigated structures in Liftweb using the built in mapper -
> is there any concern I should have?
>
> Thanks, Philip
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
