On Fri, Oct 9, 2009 at 5:29 AM, David Calavera <[email protected]> wrote: > Hi, > > I've been hacking around Jibernate and I'd like to start an open discussion > about the project and its future. > > Right now the project is not useful at all, it's just a wrapper to create > basic models with attributes, it has some bugs, it's not gemified... But, > from the point of view of an old hibernate user it has a promising future. > Hibernate is more mature than other orm frameworks like ActiveRecord or > DataMapper and since rails 3 is decoupling its layers it could be a good > choice for old java developers moving to rails that want to use this > framework.
I agree, and think we need a renewed look at integration with Java libraries as we try to start pushing JRuby more as a full platform for hybrid Ruby/Java apps. We should probably define a couple of high-level use cases to drive development. For example, - As a Java developer I want to use Jibernate to wrap my Hibernate models so that I can reuse existing functionality and data - As a Ruby developer I want to use Jibernate as an ORM backend for Rails 3 so that I can leverage the performance and stability of a popular ORM like Hibernate > So, for me, the final goal for the project should be to be fully compatible > with rails 3. Meanwhile there are a lot of work to do. > > Yesterday evening I forked Nick Sieger's repository, > http://github.com/calavera/jibernate, and I started to clean directory > structure a little bit, doing some little changes and adding some tests. I > also moved the mapping template generation to Erubis, it's faster than ERB, > it can cache templates and avoids object bindings. No problem with Erubis overall, but is it worth the dependency? Generating mapping XMLs shouldn't normally be a huge performance hit, right? > So, I think this is a good point to start working but there are a few points > to discuss-decide: > > - should it have its own place? right now I forked Nick that forked > Charlie, I think it should be move to a more appropriate place, like > github.com/jruby/jibernate or kenai.com/projects/jibernate See also Ola's Ribs library: http://github.com/olabini/ribs. We should see if there are some synergies with Ribs that can be leveraged. I'd like to see the core team promote, recommend and maintain only one Hibernate wrapper if possible. Ola did Ribs a while ago and not much has happened since then; Charlie started Jibernate as a driver for Java class generation (ruby.*). They were built for different purposes but we should do a little work to see if they can be brought together. > - should we use a gem build tool to package it? right now there isn't a > way to create a gem. Projects like Jeweler alow to package and distribute > gems easily but it can also be done by hand. I vote to use Jeweler. Go ahead, I have no preferences here. > There are also other questions about the design of the api, how to implement > relationships?, should we support the full hibernate api? should we use the > rails convention for database names or another one?... I agree with Charlie's assertions about there being a lower level wrapper around Hibernate that takes care of that level of things. Adding APIs on top for relations should take into consideration ActiveRelation, ActiveRecord, DM if possible and not try to reinvent a new API. > The main problem with this api is how hibernate works. When you add a > mapping file to the configuration it tries to load all classes related with > it, so when it adds the Parent mapping it tries to load the Child class and > it checks accessors are right, but it breaks because the other class is not > defined, you can try to load the child class first, but it also needs the > Parent class... blah blah, resulting an infinite loop. Yeah, sounds like we need to make sure all attributes and classes are defined first and then have all the hbm.xml files loaded at once. Charlie, when I spent some time on Jibernate before JavaZone I looked for an API to programatically define the models, but as far as I can see, the .hbm.xml is it. So we'll probably have to stick with that for now, and automate/wrap it. /Nick --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
