I agree that a compiler plugin seems a bit problematic; using one would mean that JPA-enabled Lift apps are no longer really "pure scala."
It seems to me that the principal problem is that JPA doesn't really live up to the ideal of keeping the meaning with the bytes, which the Record/Field design is focused on doing. So whatever solution we come up with will have to decorate "dumb" classes with some extra sauce for integration. Another use case to consider (and the one I'm trying to figure out how to shoehorn in) is how to wrap JPA entity classes from an existing Java codebase to integrate them with Record/Field. The simple solution of adding getters and setters that delegate to an underlying Field doesn't really solve this; it's almost the inverse that is needed. It's almost as if what one needs is the ability to do implicit transformations to wrap bare fields with rich wrappers, but I'm not sure how to get the extra metadata needed into the wrapper. Just brainstorming here, but would it work to modify the Record/field constructors to take a pair of functions (a getter and a setter) that are used internally to manipulate the bytes? Something like: class StringField[OwnerType <: Record[OwnerType]](rec: OwnerType, maxLength: Int, get: => String, set: String => Unit) except maybe with get and set being implicit parameters to provide the current functionality. If that were the case, it might only require something like this (not sure of what the annotation syntax should really look like): @Column(name = "foo") var myFoo : String object foo extends StringField(this, 100, myFoo, myFoo_= _) I'm not sure how exactly this would play out with respect to n:n relationships between record types, but it might be a start. Kris On Fri, Nov 28, 2008 at 12:31 PM, Marius <[EMAIL PROTECTED]> wrote: > > IMHO I'd stay away from compiler's plugins (in this context) not > because I don't like them ... but it's just another thing that > potentially makes a bitter Lift users experience. Not to mention > potential problems that raise with IDE's integration (extra configs > etc.). > > .. but I hope I'm wrong. > > Br's, > Marius > > On Nov 28, 7:41 pm, Tim Perrett <[EMAIL PROTECTED]> wrote: > > > 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. > > > > This is a fairly good point - seamless integration is important, if > > thats what we support, more often than not people will go with what we > > support. > > > > Derek: as you are the JPA with Lift guru, what is your gut feel? If a > > compiler plugin yeilds a slicker implementation, but is a little more > > work, then we should go with that. However, if using the hibernate > > stuff yields a slick enough solution and doesn't give users ugly > > looking code, then sure, i think it could be an acceptable solution. > > > > 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 -~----------~----~----~----~------~----~------~--~---
