I never did it with JPA, that's why I mentioned that there might be
some problems to circumnavigate (my websearch turned up that it's not
possible, but I might have missed something). But on the actual
backend frameworks you can do things like that (or at least hibernate
can [1,2, also see 3 below]).
The best resource to describe what we want to do is Spring ORM [3].
They had the same problem and describe the caveats with it (see the
text box for loadtime weaving under the JPA section). If we would run
our generation through Spring ORM we should probably get away with a
Record-only setup, where Record boots Spring ORM with dynamic classes
(Maps) and configures the desired backend. The nice thing would be
that Spring is already aware of which backend you use and optimizes
accordingly.
I don't really like the fact that this adds a truckload of
dependencies to the stack (spring-{orm,beans,context,core,tx} are
required, couple more optional), but it's the easiest solution I can
think of in terms of integration and timerequirements, and it should
also be pretty stable and straightforward to use for the users (Spring
has nice documentation IMO). Oh, and just if you were wondering, this
is the supported frameworks list: Hibernate, JDO, Oracle TopLink,
iBATIS SQL Maps and JPA. The biggies are supported without even going
through JPA. Sweet.
Daniel
[1] http://forums.oracle.com/forums/message.jspa?messageID=2432779
[2] http://wiki.eclipse.org/Eclipselink/Examples/JPA/Dynamic
[3] http://static.springframework.org/spring/docs/2.5.x/reference/orm.html
On Dec 15, 9:41 pm, "Derek Chen-Becker" <dchenbec...@gmail.com> wrote:
> I've been thinking a little about the XML path and there may be a wrinkle.
> No matter how you define the XML mappings, JPA expects persistable fields to
> either be real fields (var) on the instance or getter/setter pairs; using an
> object for field a la Record still isn't either of these. I have a busy few
> weeks ahead but I'm going to do some reading in the meantime and see if we
> can come up with something transparent but easy to use.
>
> Derek
>
> On Mon, Dec 15, 2008 at 12:39 AM, Daniel Mueller
> <dan.in.a.bot...@gmail.com>wrote:
>
>
>
> > (Reactivating discussion. I guess it's been discussed more on the
> > committer list, but here you have my 2 cents anyway)
>
> > For the sake of the Record-JPA discussion, people will fall into two
> > categories when they are using lift:
> > * The first group of people have an existing, working, tested JPA/OR
> > based data access library written in Java and are looking to integrate
> > that with a webapp written in lift. They will usually be coming from
> > an enterprise background, and will have some constraints on what they
> > can develop from scratch ("no - we will not rewrite all the db access
> > code to support the new web framework").
> > * The second group doesn't have an existing data access library in
> > Java and would like to write all their new stuff with lift in Scala.
> > But maybe they have mapping/usage requirements that precludes using
> > mapper because it's too simple, or they just know their way around one
> > of the other JPA enabled OR libs and want to bank on that knowledge
> > (without writing the entire layer in Java).
> > * The third group also doesn't have an existing data access library,
> > but for some reasons, they want their OR model not only be accessible
> > from lift, but actually also from Java code. This means that they not
> > only have to be able use JPA, but that the Scala code they write has
> > to be _JPA compatible_ (Java usable JPA entities etc.).
>
> > For the first group, some sort of delegation strategy from the Record
> > entity to the JPA entity is necessary (unless you can mixin the record
> > stuff on top of an actual JPA entity?). The JPA/OR configuration is
> > already in place on the existing lib (annotations/xml). The only thing
> > that record is doing is adding another layer on top of it for
> > validation, binding to UI, maybe querying. Something like what was
> > proposed earlier by Derek should be enough
>
> > > class MyEntry extends Record[MyEntry] {
> > > var inner : RealEntry = _
>
> > > object name extends StringField(this) with Delegation
> > > name.delegate(inner.name, inner.name = _)
>
> > > ...
> > > }
>
> > Now for the second group, they probably would like to have all the
> > power associated with a JPA/OR framework without resolving to writing
> > that layer in Java. Mind you that this is quite a different problem
> > from what the first group wants to solve.
> > * They just want to have Record entities, no separate JPA entity, no
> > delegation.
> > * They don't want to duplicate configuration from what they already
> > specify on Record entities.
> > * Have the integration as hassle free as possible, because in their
> > eyes, there is no actual delegation.
>
> > What the second group needs is a bit trickier, and most of the
> > discussion has revolved around how to make it as transparent as
> > possible (compiler plugins, byte code weaving, etc.).
>
> > Remember that for the second group of people Record is attempting to
> > solve the _exact same problem_ as JPA. It's a unifying frontend, that
> > abstracts away differences in persistence libraries. And as with JPA,
> > Record has the configuration present in code (instead of annotations
> > it just uses actual subclasses and parameters, but still).
>
> > But there's one thing that has only been mentioned on the off by
> > David.
>
> > > I believe there are ways to use Record's deep knowledge of class layouts
> > to
> > > generate data structures and/or XML to send to JPA to "do the right
> > thing."
>
> > The key point here is XML. While those annotations are a nice feature
> > for the programmer to get rid of the XML configuration from pre EJB
> > 3.0, it's less than sexy for attaching a unified API (record) to an
> > implementation library (jpa, which incidentially is another unified
> > API for the actual OR libs :/ ). But that's a feature for the
> > developer who doesn't want to specify the configuration in an XML. But
> > the XML configuration capability is still there. Generating XML from
> > Record entities (maybe even in memory) to boot the JPA/OR lib should
> > be pretty easy and doesn't require more opaque techniques (compiler
> > plugin, byte code weaving). And it can be overridden easily as well
> > even to integrate things that are not supported in Record.
> > I'm not well versed enough in JPA to make statements about whether the
> > XML configuration is feature complete compared to the annotations, and
> > how flexible the mapping can be (directly from the Record object
> > fields to the columns). I would assume that the mapping is not
> > flexible enough to work with the objects fields from Record, but maybe
> > we can start discussing strategies to solve that (using vars,
> > generating bytecode, using untyped maps as entities, generating OR lib
> > specific XML - And yes I know that with a couple of those you loose
> > some features provided by JPA).
>
> > For the third group of people, those that want to use reuse their
> > objects as Java compatible JPA entities: Do we really need that right
> > now? Are there enough real use cases to warrant the effort? Mind that
> > you can always write a Java compatible access layer for your entities
> > in Scala. In that layer you refrain from using stuff that Java doesn't
> > like and then just use that connector from your java code. IMO lift
> > shouldn't solve that problem. Although it's interesting, I don't
> > really see the benefit of having actual JPA object usable from Java.
> > As already discussed on the list, there's a whole bunch of
> > compatibility problems to make the Record entity be an actual JPA
> > entity. If we find out that solving the problem for the second group
> > is only possible if we solve this one, then fine, otherwise I
> > personally wouldn't bother to fix that thing now. You can code around
> > it and it shouldn't be that much of a problem to do so.
>
> > Pick your battles...
>
> > Daniel
>
> > On Dec 2, 1:22 am, "David Pollak" <feeder.of.the.be...@gmail.com>
> > wrote:
> > > My 2 cents:
>
> > > - I'm strongly opposed to any compiler plugins as they (1) mean that
> > IDEs
> > > will work less well and (2) they require some sort of installation (if
> > they
> > > can be rolled into the Maven building stuff, it makes this objection
> > go
> > > away)
> > > - I'm strongly opposed to mixing annotations and the Record stuff.
> > It'll
> > > just make for wicked ugly looking code.
>
> > > I believe there are ways to use Record's deep knowledge of class layouts
> > to
> > > generate data structures and/or XML to send to JPA to "do the right
> > thing."
>
> > > On Sun, Nov 30, 2008 at 7:45 AM, Derek Chen-Becker <
> > dchenbec...@gmail.com>wrote:
>
> > > > The whole point of integrating (and I use the word integrating here
> > > > loosely) is so that there's a common form framework for people to use.
> > > > Really, the point of Record as far as I can tell is to loosen and/or
> > remove
> > > > the tight coupling with the datastore, and in that sense Record is
> > > > succeeding. As Tim points out, there are going to be people with
> > existing
> > > > JPA libraries and what we're trying to propose is a means for them to
> > > > leverage their existing libraries alongside the nice work done in
> > Record. As
> > > > ugly as the boilerplate for delegation may seem, I don't see any better
> > > > solution without adding significant complexity. I've done bytecode
> > > > manipulation in the past and while it can be very handy, it makes
> > things a
> > > > lot more complex on the backend and I'm really trying to avoid
> > complexity
> > > > (this includes a compiler plugin, too).
>
> > > > Delegation provides the cleanest approach I can come up with; it
> > actually
> > > > helps in the case where someone wants to use an existing JPA library
> > because
> > > > you could simply wrap an instance and delegate to it:
>
> > > > class MyEntry extends Record[MyEntry] {
> > > > var inner : RealEntry = _
>
> > > > object name extends StringField(this) with Delegation
> > > > name.delegate(inner.name, inner.name = _)
>
> > > > ...
> > > > }
>
> > > > By adding a few lines of boilerplate in each class you get validation,
> > form
> > > > generation, presentation HTML, JSON representation, etc. It's up to the
> > > > end-user to determine whether these features are worth the cost of a
> > few
> > > > LoC.
>
> > > > I'm not saying this is a perfect solution, just that I think that this
> > is
> > > > the best first cut at it. Also, no one is saying that people have to
> > use JPA
> > > > with Record. I'm assuming that the majority of new Lift apps will
> > probably
> > > > use Record/Mapper because they're simple, easy to use and quite capable
> > of
> > > > handling most data models. But for the people with existing JPA
> > libraries,
> > > > or for people who would like to use JPA for the additional features,
> > > > compatibility with Java apps, etc, I'd like to have a better answer
> > than an
> > > > absolute "Don't use Record" or "Switch to Record".
>
> > > > Derek
>
> > > > On Sun, Nov 30, 2008 at 1:40 AM, Marius <marius.dan...@gmail.com>
> > wrote:
>
> > > >> I totally agree with you Viktor! ... although it seems like a workable
> > > >> solution in this case a Record contains to distinct entities to
> > > >> represent the same data and of course the boilerplate.
>
> > > >> It was mentioned above compiler plugins which I expressed my opinion
> > > >> about it (I'd stay away) but there might be another way to "alter" the
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
