I completely forgot Ribs. It's going forward Jibernate, it already supports many-to-one and one-to-one relations, but it uses a different approach. While Jibernate uses java classes wrapped as mapping objects, Ribs uses Property objects so it's easy to develop and it works with previous versions of Jruby.
Perhaps we should talk with Ola to see what he thinks about it, from my point of view Ribs is a little more mature but I'm not sure it's been used too much, and its api is not as friendly as AR or DM. On Mon, Oct 12, 2009 at 5:57 PM, Nick Sieger <[email protected]> wrote: > 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 > > > -- David Calavera http://www.thinkincode.net
