Hi Kevin, thanks for your reply In general the Scala community tends to invent things new (one example are the available persistence layers). This is OK, mostly, because a language like Scala has many new possibility to express things in terms of implementation and design of frameworks (DSL).
But I think that if Scala wants to have success (I am a Scala enthusiast ;-) we have to provide frameworks that allow the integration of Scala code into existing and proven environments in terms of knowledge (developer skills) and software. I do not know all the new emerging Scala persistence frameworks out there, but I am creating SW-systems for 15 years now and I know that production readiness is something different (btw, it is never a good thing to throw away what Java and the JCP invented the last years.) Thats why I am asking: What does it mean to take a common JCP (JPA 2.0) and its implementation (example OpenJPA), provide a wrapper as long it is possible and smoothly change things (what at least means drop parts of the specification). This must not be a generic solution (I am sure that this will not be possible) In the case of JPA this means using Scala collections for entities. The issue here is that these collections do not implement any of Javas interfaces and there are a lot more possibilities to choose from mutable and immutable versions. If you are interested I can post some examples of how a Scala entity should look like? Christopher On Fri, May 21, 2010 at 9:26 PM, Kevin Sutter <[email protected]> wrote: > Hi Christopher, > I took a quick look at your links. Interesting ideas. Of course, the > easiest way to allow for Scala Buffers is if Buffer extended Collection. I > don't know anything about your Buffer architecture or implementation, so I > don't know if this is even a doable question or not. As long as your data > structure could satisfy the signature requirements, then any JPA > implementation should be good to go. > > As I look at your blog post, it looks like you are hoping to work with all > three main players (OpenJPA, Hibernate, and EclipseLink). So, are you > looking for a general solution that would work with all three? Or, are you > looking for a more specific solution? Supporting the Collection interface > would be the most general. > > If you have to introduce new method signatures, then you're probably going > to have to develop a unique plug point for each JPA provider. For example, > in OpenJPA we have provided various "strategies" when working with a unique > situation. The OpenJPA extension for XML Mapping (vs Relational Mapping) is > a separate XMLValueHandler strategy. You might need to think about creating > something like the ScalaBuffer strategy which would know how to interact > with your Buffers (vs Collections). > > Just some quick thoughts after reading your post. > > Kevin > > On Fri, May 21, 2010 at 9:28 AM, Christopher Schmidt < > [email protected]> wrote: > >> Hi all, >> I am working on a JPA wrapper for Scala and I think that I have found >> an elegant way to use some ideas of JPA. >> I managed to wrap EntityManager, EntitiyManagerFactory and Query. >> >> Unfortunately, there is no simple and elegant way to use Scala's >> collections. Using Scala classes as entities works fine, as long they >> are using java.lang.List (and the other collections that are >> specified). >> >> My question is: What would it mean (in terms of effort and knowledge) >> to allow a Scala collection (f.e. a Buffer) as a OneToMany entity >> attribute? >> >> Regards Christopher >> >> >> >> PS: >> >> Buffer is Scala's mutable "List" implementation (see >> >> http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/scala/collection/mutable/Buffer.html >> ) >> >> If you are interested look at http://blog.fakod.eu/?p=855 >> (description) and http://github.com/FaKod/JPA-for-Scala (code) >> >
