On Fri, Oct 9, 2009 at 4:29 AM, David Calavera <[email protected]> wrote: > 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. > > 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.
Rails 3 is obviously a big and important target, but I'd like this to be full-featured enough that people could use it outside of Rails as well, such as for local embedded databases, pre-3.0 Rails apps, and so on. Like a GORM for JRuby that just happens to also be the backend for AR-Hibernate. > 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. I'm hoping that we can make the "hibernate_attr" API (or something similar) generate the mappings directly, rather than having to go out to XML and back. This would give us maximum flexibility in how we work with the hibernate API. But in the short term, anything to eliminate the XML is good. > 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 Either is fine with me, but I agree we should centralize it now. > - 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. I have no preference, but I think it should be available as a gem. Right now all it depends on is the main hibernate jar (plus a JDBC jar, obviously), which I think we can redistribute easily. We probably should have a standalone "hibernate" gem that just contains that jar, so any other projects that want to reference it can, and if we need to updated hibernate we don't necessarily have to re-release jibernate. > 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 think we make Jibernate be basically syntactic sugar around Hibernate. We'll add what we can as Ruby wrappers (where it seems appropriate) and allow other things to just call Hibernate directly. By making it reasonably low level (with sugar where it's really necessary), we can then build Rails 3.0 support on top of Jibernate (or DM support, or whatever). And actually, DM may be a great first API to support...a DM-Hibernate might be a good fit between API and underlying library features, and the DM API has had a few revisions...it's pretty nice. > As my first task I'd like to write a basic implementation of relationships, > one-to-many and many-to-one. This is how I think the api should be: > > class Parent > include Hibernate::Model > hibernate_has_many :children => Child > hibernate! > end > > It should generate > <set name="children"> > <key column="CHILDREN_ID"/> > <one-to-many class="ruby.Child"/> > </set> I see you know Hibernate :) That's better than me...I was just working through the tutorials. This looks pretty good, though again I feel like we'd be better off going straight to the mapping APIs. But yes, generated XML is a good first pass. This feels pretty Railsy to me, which is fine, but are you familiar with DM at all? I think we should try to go with "working but not a lot of magic+dsl stuff" first, and then look at DSL stuff as being ActiveRecord or DM or something atop our base structure. I just don't want to hide too much of Hibernate too early, lest we make it impossible to wire up certain unusual cases. > class Child > include Hibernate::Model > hibernate_belongs_to :parent => Parent > hibernate! > end > > it should generate > <many-to-one name="parent" class="ruby.Parent" column="PARENT_ID"/> > > 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. Do we avoid some of this by going directly to the mapping APIs? My feeling about the XML descriptors is that they're designed to be totally isolated from the classes they describe, and the entire shebang then wants to be loaded all at once. Via the mapping APIs, I feel like we'd have more freedom to construct associations lazily, once everything's up and running. But I am not intimately familiar with Hibernate's APIs... - Charlie --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
