[Lift] Re: JPA and Record
I know what you mean, I have the same feelings about it. Spring can be
a big mess (it's pretty certainly making a mess of your classpath with
all those deps). On the other hand, I just tried to find out how big a
mess it actually would be. It's substantial but not frightening IMO.
Adding the spring dependencies (only the relevant ones) is adding
almost the same as the hibernate.jar alone.
aopalliance-1.0.jar
commons-logging-1.1.1.jar
spring-beans-2.5.6.jar
spring-context-2.5.6.jar
spring-core-2.5.6.jar
spring-orm-2.5.6.jar
spring-tx-2.5.6.jar
~= 1.8M
hibernate-3.2.6.ga.jar
~= 2.2M
I didn't include annotations and EM on the hibernate side, they add
together something like 200k, and I might have missed something on the
spring side (the rest of the deps are optional, some might be needed
though).
Not really arguing here, just trying to not get into FUD.
Daniel
PS: I just did that with downloading from the maven repo directly, but
if you have a working project you want to inspect the jars from: get
the executed commandline somehow, split in vi with :%s/:/^M/
g (that's CTRL-V CTRL-M), save to cp.txt, then cp `grep spring
cp.txt` . or whatever you like (du `grep spring cp.txt` | sort -
nr). Nice way to check your classpath.
On Dec 16, 5:32 am, Derek Chen-Becker dchenbec...@gmail.com wrote:
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.comwrote:
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.comwrote:
(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
[Lift] Re: JPA and Record
Don't get me wrong, I've used Spring before to great benefit. My biggest
concern is that it uses commons-logging, which complicates logging config a
bit.It also expands the POM via those dependencies. Bottom line: I'd like to
avoid it if we can, but I don't have a problem if it ends up being the best
way to do it.
Derek
On Mon, Dec 15, 2008 at 10:08 PM, Daniel Mueller
dan.in.a.bot...@gmail.comwrote:
I know what you mean, I have the same feelings about it. Spring can be
a big mess (it's pretty certainly making a mess of your classpath with
all those deps). On the other hand, I just tried to find out how big a
mess it actually would be. It's substantial but not frightening IMO.
Adding the spring dependencies (only the relevant ones) is adding
almost the same as the hibernate.jar alone.
aopalliance-1.0.jar
commons-logging-1.1.1.jar
spring-beans-2.5.6.jar
spring-context-2.5.6.jar
spring-core-2.5.6.jar
spring-orm-2.5.6.jar
spring-tx-2.5.6.jar
~= 1.8M
hibernate-3.2.6.ga.jar
~= 2.2M
I didn't include annotations and EM on the hibernate side, they add
together something like 200k, and I might have missed something on the
spring side (the rest of the deps are optional, some might be needed
though).
Not really arguing here, just trying to not get into FUD.
Daniel
PS: I just did that with downloading from the maven repo directly, but
if you have a working project you want to inspect the jars from: get
the executed commandline somehow, split in vi with :%s/:/^M/
g (that's CTRL-V CTRL-M), save to cp.txt, then cp `grep spring
cp.txt` . or whatever you like (du `grep spring cp.txt` | sort -
nr). Nice way to check your classpath.
On Dec 16, 5:32 am, Derek Chen-Becker dchenbec...@gmail.com wrote:
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.comwrote:
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.comwrote:
(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
[Lift] Re: JPA and Record
Mmh, the commons-logging problem you can neatly circumnavigate with
SLF4J and the appropriate bridges. And I absolutely agree with you,
this is not the preferred solution, nor the one that will win you the
style award, but it's probably the one that you can get up and running
with the least effort and reinventing the wheel portion. Might also be
just an intermediate solution or something that is in a contrib folder
somewhere (same status as your current non-Record JPA efforts
probably).
Aye, anyway, I think we agree on what the advantages and disadvantages
are and can look around for solutions that are neater. If I come up
with something I'll post it.
Daniel
On Dec 16, 9:28 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
Don't get me wrong, I've used Spring before to great benefit. My biggest
concern is that it uses commons-logging, which complicates logging config a
bit.It also expands the POM via those dependencies. Bottom line: I'd like to
avoid it if we can, but I don't have a problem if it ends up being the best
way to do it.
Derek
On Mon, Dec 15, 2008 at 10:08 PM, Daniel Mueller
dan.in.a.bot...@gmail.comwrote:
I know what you mean, I have the same feelings about it. Spring can be
a big mess (it's pretty certainly making a mess of your classpath with
all those deps). On the other hand, I just tried to find out how big a
mess it actually would be. It's substantial but not frightening IMO.
Adding the spring dependencies (only the relevant ones) is adding
almost the same as the hibernate.jar alone.
aopalliance-1.0.jar
commons-logging-1.1.1.jar
spring-beans-2.5.6.jar
spring-context-2.5.6.jar
spring-core-2.5.6.jar
spring-orm-2.5.6.jar
spring-tx-2.5.6.jar
~= 1.8M
hibernate-3.2.6.ga.jar
~= 2.2M
I didn't include annotations and EM on the hibernate side, they add
together something like 200k, and I might have missed something on the
spring side (the rest of the deps are optional, some might be needed
though).
Not really arguing here, just trying to not get into FUD.
Daniel
PS: I just did that with downloading from the maven repo directly, but
if you have a working project you want to inspect the jars from: get
the executed commandline somehow, split in vi with :%s/:/^M/
g (that's CTRL-V CTRL-M), save to cp.txt, then cp `grep spring
cp.txt` . or whatever you like (du `grep spring cp.txt` | sort -
nr). Nice way to check your classpath.
On Dec 16, 5:32 am, Derek Chen-Becker dchenbec...@gmail.com wrote:
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.comwrote:
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
[Lift] Re: JPA and Record
(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
[Lift] Re: JPA and Record
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.comwrote:
(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
[Lift] Re: JPA and Record
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.comwrote:
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.comwrote:
(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
[Lift] Re: JPA and Record
Hi Derek,
Is there any demo code for this NEW record method of accessing/using
database?
Is there any docs on it?
I want to understand it but don't know where to start - I know there
is the other legacy way to do it and JPA.
Thanks, Philip
On Nov 26, 2:24 am, Derek Chen-Becker dchenbec...@gmail.com wrote:
We just had a bit of a discussion on integrating JPA with the new Record
stuff over on the committers list and unintentionally got into some
substance discussion that would be better handled on the main list. Let me
sum up:
First off, the new Record stuff looks great! It's lean, it's mean and it's
clean. There is still some work to do on fleshing out some implementation
details and maybe fleshing out some of the base Field support (I'm doing a
BigDecimal-based field for a book example, would people want to see that?),
but what's there so far is very nice; David and Marius have done a great
job.
The issue with JPA, specifically, is that the way it's designed, it infers
persistent fields on an instance either via getter/setter pairs or via
annotations on fields. Record, for reasons that I think are completely
legitimate, uses instance objects instead for field definition. These two
approaches aren't mutually exclusive, but it does complicate things a bit
from the JPA perspective. The simplest approach I can think of is to merely
add the appropriate getter/setter pairs that delegate to the Record object
fields, like this:
class MyEntity extends Record[MyEntity] {
object name extends StringField(this,100)
// getter/setter used only by the JPA provider
@Column{val name = my_name_}
def getName() = name.value
def setName(newVal : String) = name.set(newVal)
}
This should work, but it does add quite a bit of what is essentially
boilerplate to the code. I'm hoping that I can find some way to automate or
generate the appropriate getter/setter pairs for the fields. If anyone has
any suggestions I would love to hear it.
Thanks,
Derek
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Lift] Re: JPA and Record
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 [EMAIL PROTECTED]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 [EMAIL PROTECTED] 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
bytecode at runtime. I'm talking about dynamic class weaving.
Basically it is a class loader that before returning the actual
updated class. Kind of what AspectJ is doing. A while ago a wrote a
bytecode level manipulation framework and combined with a special
classloader I was able to modify a class dynamically and use it.
Of course there are caveats:
1. Complexity induced by bytecode level manipulation
2. How a dynamic class loader cope with container's classloader that
essentially loads the web application. Of course it would delegate the
loading to the container's classloader but these modifiable classes
should probably not live in WEB-INF/classes or WEB-INF/lib folder.
But all in all I'm not convinced that this effort really worth it.
AFAIC I still don;t get the whole point of integrating Record/Field
with JPA. If someone wants to switch easily from JPA to Record or vice-
versa, to have this flexibility perhaps consider to abstract these
layers from the rest of the application and using other persistence
technologies would not affect the application business logic ... but
this is about how the appliation is designed etc.
Br's,
Marius
On Nov 30, 9:56 am, Viktor Klang [EMAIL PROTECTED] wrote:
IMHO:
@Column{val name = my_name}
var name : String = _
object nameField extends StringField(this,100) with Delegated
nameField.delegate(name, name = _)
That's just too much boilerplate. For me, who went to scala to lose
boilerplate, this is not a viable solution.
Unfortunately the JPA spec is kind of weak when it comes to adaptation,
so
my suggestion to make it work with Hibernate first still stands.
What do you guys think?
Cheers,
Viktor
On Sat, Nov 29, 2008 at 10:23 PM, Derek Chen-Becker
[EMAIL PROTECTED]wrote:
No big deal. In the example code I did a by-name in the delegate
method so
at least it's transparent to the
[Lift] Re: JPA and Record
- I'm pretty close to having a releasable version of the maven-scala-plugin
that supports compiler plugins.
- Adding integration between the maven-pom and eclipse is going to take some
time (but is possible). I'm not sure about the netbeans/IntelliJ tools,
but this could be an awkward integration for all of them.
Don't know if that helps. (Personally I think compiler plugins are better
for POCs).
On Mon, Dec 1, 2008 at 1:22 PM, David Pollak
[EMAIL PROTECTED]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 [EMAIL PROTECTED]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 [EMAIL PROTECTED] 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
bytecode at runtime. I'm talking about dynamic class weaving.
Basically it is a class loader that before returning the actual
updated class. Kind of what AspectJ is doing. A while ago a wrote a
bytecode level manipulation framework and combined with a special
classloader I was able to modify a class dynamically and use it.
Of course there are caveats:
1. Complexity induced by bytecode level manipulation
2. How a dynamic class loader cope with container's classloader that
essentially loads the web application. Of course it would delegate the
loading to the container's classloader but these modifiable classes
should probably not live in WEB-INF/classes or WEB-INF/lib folder.
But all in all I'm not convinced that this effort really worth it.
AFAIC I still don;t get the whole point of integrating Record/Field
with JPA. If someone wants to switch easily from JPA to Record or vice-
versa, to have this flexibility perhaps consider to abstract these
layers from the rest of the application and using other persistence
technologies would not affect the application business logic ... but
this is about how the appliation is designed etc.
Br's,
Marius
On Nov 30, 9:56 am, Viktor Klang [EMAIL PROTECTED] wrote:
IMHO:
@Column{val name = my_name}
var name : String = _
object nameField extends StringField(this,100) with Delegated
nameField.delegate(name, name = _)
That's just too much boilerplate.
[Lift] Re: JPA and Record
On Dec 1, 8:22 pm, David Pollak [EMAIL PROTECTED]
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 not sure about people hat love lift but hate maven (if there are
any) ... would we want to force them to love maven if they want JPA
Record :) ?
- 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 [EMAIL PROTECTED]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 [EMAIL PROTECTED] 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
bytecode at runtime. I'm talking about dynamic class weaving.
Basically it is a class loader that before returning the actual
updated class. Kind of what AspectJ is doing. A while ago a wrote a
bytecode level manipulation framework and combined with a special
classloader I was able to modify a class dynamically and use it.
Of course there are caveats:
1. Complexity induced by bytecode level manipulation
2. How a dynamic class loader cope with container's classloader that
essentially loads the web application. Of course it would delegate the
loading to the container's classloader but these modifiable classes
should probably not live in WEB-INF/classes or WEB-INF/lib folder.
But all in all I'm not convinced that this effort really worth it.
AFAIC I still don;t get the whole point of integrating Record/Field
with JPA. If someone wants to switch easily from JPA to Record or vice-
versa, to have this flexibility perhaps consider to abstract these
layers from the rest of the application and using other persistence
technologies would not affect the application business logic ... but
this is about how the appliation is designed etc.
Br's,
Marius
On Nov 30, 9:56 am, Viktor Klang [EMAIL PROTECTED] wrote:
IMHO:
[EMAIL PROTECTED] name = my_name}
var name : String = _
object nameField extends StringField(this,100) with Delegated
nameField.delegate(name, name = _)
That's just too much boilerplate. For me, who went to scala to lose
boilerplate, this is not a viable solution.
Unfortunately the JPA spec is kind of weak when it comes to adaptation,
so
my suggestion to make it work
[Lift] Re: JPA and Record
But all in all I'm not convinced that this effort really worth it. AFAIC I still don;t get the whole point of integrating Record/Field with JPA. Over the time i've been working with lift there has been much discussion about unified validation, and hooking various persistence backend's. I remember a particular discussion that was had about mapper, and how appropriate it was for use within a large applications, and DPP suggested that mapper was good up until about 20 database tables - I think the phrase was quick and dirty. At the time we had no JPA support what-so-ever and Record seemed like a far away ideal which promised a way of hooking in tech's like JPA and still get all the cool lift features. Now we have Record, it seems like we wouldn't have made a great step forward if mapper is still the only first line persistence mechanism and we still have no abstract way to handle validation? I know record brings a bunch of stuff to the table and its not just mapper on steroids, but it seems like we should be able to provide a way of hooking Record into JPA as there will no doubt be a lot of users that have existing Hibernate and/or JPA tiers and want to use lift - especially within the enterprise space. I cant really suggest a way forward, as I'm no JPA expert, but what i can do is argue for its support and how important it is we provide some level of integration. We know that JPA is a lot more complicated to implement anyway right now in lift, but perhaps we look for a staged approach of implementation? Start by providing something loose, that requires the user to jump through some more hoops, then as time progresses upgrade that support to something more streamlined (and i.e. more complex for us to create)? Just my two cents :) Cheers, Tim --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: JPA and Record
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 [EMAIL PROTECTED] 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
bytecode at runtime. I'm talking about dynamic class weaving.
Basically it is a class loader that before returning the actual
updated class. Kind of what AspectJ is doing. A while ago a wrote a
bytecode level manipulation framework and combined with a special
classloader I was able to modify a class dynamically and use it.
Of course there are caveats:
1. Complexity induced by bytecode level manipulation
2. How a dynamic class loader cope with container's classloader that
essentially loads the web application. Of course it would delegate the
loading to the container's classloader but these modifiable classes
should probably not live in WEB-INF/classes or WEB-INF/lib folder.
But all in all I'm not convinced that this effort really worth it.
AFAIC I still don;t get the whole point of integrating Record/Field
with JPA. If someone wants to switch easily from JPA to Record or vice-
versa, to have this flexibility perhaps consider to abstract these
layers from the rest of the application and using other persistence
technologies would not affect the application business logic ... but
this is about how the appliation is designed etc.
Br's,
Marius
On Nov 30, 9:56 am, Viktor Klang [EMAIL PROTECTED] wrote:
IMHO:
@Column{val name = my_name}
var name : String = _
object nameField extends StringField(this,100) with Delegated
nameField.delegate(name, name = _)
That's just too much boilerplate. For me, who went to scala to lose
boilerplate, this is not a viable solution.
Unfortunately the JPA spec is kind of weak when it comes to adaptation,
so
my suggestion to make it work with Hibernate first still stands.
What do you guys think?
Cheers,
Viktor
On Sat, Nov 29, 2008 at 10:23 PM, Derek Chen-Becker
[EMAIL PROTECTED]wrote:
No big deal. In the example code I did a by-name in the delegate method
so
at least it's transparent to the end-user.
Derek
On Sat, Nov 29, 2008 at 11:06 AM, Jorge Ortiz [EMAIL PROTECTED]
wrote:
Just wanted to chime in real quick...
type Getter = () = MyType // Can this be by-name in any way?
No. By-names are not first-class types. It's gotta be () = MyType
--j
--
Viktor Klang
Senior Systems Analyst
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
[Lift] Re: JPA and Record
I just thinked again. As I understand, Record like Mapper have no special
support for one-to-many or many-to-many relations. And lazy-loading is used
mostly in such scenarios. So maybe this code is really enough to blend
Record features with JPA's:
object name extends StringField(this,100)
@Column{val name = my_name}
def getName() = name.value
def setName(newVal : String) = name.set(newVal)
Or am I wrong now? And can this work with Mapper too?
Maybe an interesting thing to do as part of JPA integration effort would be
to wrap JPA query language in a typesafe API like one in Mapper. Maybe it is
far easier than to code support for JPA/Hibernate object-oriented query
features in Mapper/Record. What do you think?
On Sun, Nov 30, 2008 at 5:45 PM, Derek Chen-Becker [EMAIL PROTECTED]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 [EMAIL PROTECTED] 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
bytecode at runtime. I'm talking about dynamic class weaving.
Basically it is a class loader that before returning the actual
updated class. Kind of what AspectJ is doing. A while ago a wrote a
bytecode level manipulation framework and combined with a special
classloader I was able to modify a class dynamically and use it.
Of course there are caveats:
1. Complexity induced by bytecode level manipulation
2. How a dynamic class loader cope with container's classloader that
essentially loads the web application. Of course it would delegate the
loading to the container's classloader but these modifiable classes
should probably not live in WEB-INF/classes or WEB-INF/lib folder.
But all in all I'm not convinced that this effort really worth it.
AFAIC I still don;t get the whole point of integrating Record/Field
with JPA. If someone wants to switch easily from JPA to Record or vice-
versa, to have this flexibility perhaps consider to abstract these
layers from the rest of the application and using other persistence
technologies would not affect the application business logic ... but
this is about how the appliation is designed etc.
Br's,
Marius
On Nov 30, 9:56 am, Viktor Klang [EMAIL PROTECTED] wrote:
IMHO:
@Column{val name = my_name}
var name : String = _
object nameField extends StringField(this,100) with Delegated
nameField.delegate(name, name = _)
That's just too much boilerplate. For me, who went to scala to lose
boilerplate, this is not a viable solution.
Unfortunately the JPA spec is kind of weak when it comes to adaptation,
so
my suggestion to make it work with Hibernate first still stands.
What do you guys think?
Cheers,
Viktor
On Sat,
[Lift] Re: JPA and Record
No big deal. In the example code I did a by-name in the delegate method so at least it's transparent to the end-user. Derek On Sat, Nov 29, 2008 at 11:06 AM, Jorge Ortiz [EMAIL PROTECTED] wrote: Just wanted to chime in real quick... type Getter = () = MyType // Can this be by-name in any way? No. By-names are not first-class types. It's gotta be () = MyType --j --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: JPA and Record
IMHO:
@Column{val name = my_name}
var name : String = _
object nameField extends StringField(this,100) with Delegated
nameField.delegate(name, name = _)
That's just too much boilerplate. For me, who went to scala to lose
boilerplate, this is not a viable solution.
Unfortunately the JPA spec is kind of weak when it comes to adaptation, so
my suggestion to make it work with Hibernate first still stands.
What do you guys think?
Cheers,
Viktor
On Sat, Nov 29, 2008 at 10:23 PM, Derek Chen-Becker
[EMAIL PROTECTED]wrote:
No big deal. In the example code I did a by-name in the delegate method so
at least it's transparent to the end-user.
Derek
On Sat, Nov 29, 2008 at 11:06 AM, Jorge Ortiz [EMAIL PROTECTED]wrote:
Just wanted to chime in real quick...
type Getter = () = MyType // Can this be by-name in any way?
No. By-names are not first-class types. It's gotta be () = MyType
--j
--
Viktor Klang
Senior Systems Analyst
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: JPA and Record
Hi, Derek.
I just want to post an opinion. Compiler plugin might be cool, but could get
tricky. I think the important part of JPA is a transparent lazy-loading. And
Hibernate can even optimize it with batch fetching strategies. It seems like
lazy-loading might not work if you access entity fields through scala code
directly without a getter. Hm. But we can always write our own batch
fetching...
I would second the suggestion to use simple hibernate specific
PropertyAccessors. Special objects Tuplizers are responsible for creating
PropertyAccessors.
http://hibernate.org/hib_docs/v3/reference/en/html/persistent-classes-tuplizers.html
Maybe PropertyAccessors will be not enough. There are also ProxyFactories in
hibernate which are responsible for creating proxied objects. There are
default implementations for POJOs, Maps and Dom4j trees.
http://hibernate.org/hib_docs/reference/en/html/persistent-classes-dynamicmodels.html
But proxies were required to intercept getters calling. And with records
design they might be obsolete. Much java libraries bytecode magic can be
eliminated by good scala code design:)
I personally use JPA in java projects but don't hesitate to use hibernate
specific features. Some of them are very addictive. And I've never had to
switch hibernate to other JPA implementation. I think that standards are
important, but usefullness of an api is more important than its
standardness.
So if a general JPA integration proves to be hard then I see value in just
having seamless integration of JPA/hibernate with Lift features. And if
somebody wants to use other JPA-impl, they can always use it just the way
they can use it today.
Hope this is useful. And thank you for your efforts!
On Wed, Nov 26, 2008 at 5:07 PM, Derek Chen-Becker [EMAIL PROTECTED]wrote:
Well, I don't necessarily think that's a bad idea. In fact, I was thinking
about that as well last night. I'm really not familiar at all with how
complex it would be to write a compiler plugin, or how easy that would be to
integrate with Maven. What I was thinking of, at least, was combining a
compiler plugin and somehow transposing JPA annotations that appear on a
Record field onto a generated getter/setter pair. Thus:
class MyEntry extends Record[MyEntry] {
@Column{val name = my_name}
object name extends StringField(this,100)
}
would become:
class MyEntry extends Record[MyEntry] {
object name extends StringField(this,100)
@Column{val name = my_name}
def getName() = name.value
def setName(newVal : String) = name.set(newVal)
}
Is there anyone here who can comment on how viable that is, or should I ask
on the Scala list?
Thanks,
Derek
On Wed, Nov 26, 2008 at 1:00 AM, Mateusz Fiołka [EMAIL PROTECTED]wrote:
I'm not sure if my idea is good but I think that wrong ideas are better
the none so I post it. Some time ago there was a discussion about using
scala compiler plugins to simplify lift users experience. I'm not sure what
are your opinions about using it in lift, however I guess it could help alot
in this case. Class extending Record could be specially treated by compiler
and thus record objects could be specified in a very simple way. I know
there is added dependency to the build process but imho it's much better
then using code generators because it is one of the compilation phases and
it must be run for the code to compile.
On Tue, Nov 25, 2008 at 10:29 PM, Kris Nuttycombe
[EMAIL PROTECTED] wrote:
Ah, right, so if you're using property-based inference anyway, it's not
an issue. Never mind.
On Tue, Nov 25, 2008 at 2:26 PM, Derek Chen-Becker
[EMAIL PROTECTED] wrote:
On Tue, Nov 25, 2008 at 1:40 PM, Kris Nuttycombe
[EMAIL PROTECTED] wrote:
Remember that additionally in JPA, a bare unannotated field on an
object will be inferred as persistent unless annotated @Transient (or, in
java, unless it is declared with the transient modifier)
My reading of the JPA spec, section 2.1.1 is that persistent state is
either field-based or property-based, and is determined by where you place
your annotations. The @Transient is required for either method where you
have a field or property that isn't supposed to be part of the state.
Derek
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: JPA and Record
Well, I don't necessarily think that's a bad idea. In fact, I was thinking
about that as well last night. I'm really not familiar at all with how
complex it would be to write a compiler plugin, or how easy that would be to
integrate with Maven. What I was thinking of, at least, was combining a
compiler plugin and somehow transposing JPA annotations that appear on a
Record field onto a generated getter/setter pair. Thus:
class MyEntry extends Record[MyEntry] {
@Column{val name = my_name}
object name extends StringField(this,100)
}
would become:
class MyEntry extends Record[MyEntry] {
object name extends StringField(this,100)
@Column{val name = my_name}
def getName() = name.value
def setName(newVal : String) = name.set(newVal)
}
Is there anyone here who can comment on how viable that is, or should I ask
on the Scala list?
Thanks,
Derek
On Wed, Nov 26, 2008 at 1:00 AM, Mateusz Fiołka [EMAIL PROTECTED]wrote:
I'm not sure if my idea is good but I think that wrong ideas are better the
none so I post it. Some time ago there was a discussion about using scala
compiler plugins to simplify lift users experience. I'm not sure what are
your opinions about using it in lift, however I guess it could help alot in
this case. Class extending Record could be specially treated by compiler and
thus record objects could be specified in a very simple way. I know there is
added dependency to the build process but imho it's much better then using
code generators because it is one of the compilation phases and it must be
run for the code to compile.
On Tue, Nov 25, 2008 at 10:29 PM, Kris Nuttycombe
[EMAIL PROTECTED] wrote:
Ah, right, so if you're using property-based inference anyway, it's not an
issue. Never mind.
On Tue, Nov 25, 2008 at 2:26 PM, Derek Chen-Becker [EMAIL PROTECTED]
wrote:
On Tue, Nov 25, 2008 at 1:40 PM, Kris Nuttycombe
[EMAIL PROTECTED] wrote:
Remember that additionally in JPA, a bare unannotated field on an object
will be inferred as persistent unless annotated @Transient (or, in java,
unless it is declared with the transient modifier)
My reading of the JPA spec, section 2.1.1 is that persistent state is
either field-based or property-based, and is determined by where you place
your annotations. The @Transient is required for either method where you
have a field or property that isn't supposed to be part of the state.
Derek
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: JPA and Record
On Tue, Nov 25, 2008 at 11:24 AM, Derek Chen-Becker
[EMAIL PROTECTED]wrote:
We just had a bit of a discussion on integrating JPA with the new Record
stuff over on the committers list and unintentionally got into some
substance discussion that would be better handled on the main list. Let me
sum up:
First off, the new Record stuff looks great! It's lean, it's mean and it's
clean. There is still some work to do on fleshing out some implementation
details and maybe fleshing out some of the base Field support (I'm doing a
BigDecimal-based field for a book example, would people want to see that?),
but what's there so far is very nice; David and Marius have done a great
job.
Fields with custom type mappings are pretty important, and unfortunately
they're not in the base JPA spec. Hibernate has its @Type annotation, so
whatever solution we come up with should be extensible to the degree that it
be able to accommodate such extensions.
The issue with JPA, specifically, is that the way it's designed, it infers
persistent fields on an instance either via getter/setter pairs or via
annotations on fields.
Remember that additionally in JPA, a bare unannotated field on an object
will be inferred as persistent unless annotated @Transient (or, in java,
unless it is declared with the transient modifier)
Record, for reasons that I think are completely legitimate, uses instance
objects instead for field definition. These two approaches aren't mutually
exclusive, but it does complicate things a bit from the JPA perspective. The
simplest approach I can think of is to merely add the appropriate
getter/setter pairs that delegate to the Record object fields, like this:
class MyEntity extends Record[MyEntity] {
object name extends StringField(this,100)
// getter/setter used only by the JPA provider
@Column{val name = my_name_}
def getName() = name.value
def setName(newVal : String) = name.set(newVal)
}
I haven't had time to look at Record yet, but could you elaborate on the
reasons for using object for field definitions? It seems like this would
make mapping class hierarchies problematic, although I may be
misunderstanding.
Kris
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
