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 [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
