That may be workable but I have to recoil a little when we talk about
bringing Spring into the mix. It has its purpose but I would hate to make it
an implicit requirement of using Record with JPA; it's just huge.
Derek
On Mon, Dec 15, 2008 at 12:46 PM, Daniel Mueller
<dan.in.a.bot...@gmail.com>wrote:
>
> 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
-~----------~----~----~----~------~----~------~--~---
