The reason I think of Hobo and No SQL data stores like MongoDB as a perfect fit has been my long search for a replacement of the Revelation 4GL that I started using in 1984.
Revelation was a "NoSQL" PC port of the powerful Pick operating system that was way ahead of its time. It started in 1968. When did Oracle start? " -) What allowed Revelation (and Advanced Revelation) to be the key "Aglle" tool (IMHO) of the 1980's and 1990's was the variable length, multi-valued record structure s, Symbolic (calculated) fields, and the interpreted and powerful imbedded structural language that was included. It did not require "migrations" as you changed the database structures. That allowed for fast and incremental adjustments to an application. Sound familiar? -Owen On Mon, Dec 20, 2010 at 10:24 PM, Henry Baragar < [email protected]> wrote: > On December 20, 2010 02:58:10 pm Matt Jones wrote: > > > On Dec 20, 2010, at 12:12 PM, Henry Baragar wrote: > > > > Hello, > > > > I have a prospect for which MongoDB would be a good fit. > > > > Has anyone used MongoDB with Hobo? > > > > If not, how easy would it be to add? Could the schema generator be > used? > > > > Henry > > > > > > I'm not sure what the schema generator would be used to *do* - after all, > > > not much schema in NoSQL. :) > > > > > Document-oriented NoSQL databases (such as mongoDB) tend to have "dynamic > schemas" (as alluded to below). > > > That said, nothing is going to work directly (too many dependencies on > > > ActiveRecord, and correspondingly too many hooks into AR as well) but > it's > > > an open question how much can be reused. For instance, the core of > > > Hobofields (the DSL and the field spec stuff) should be fairly similar > and > > > adaptable to the way that (for instance) MongoMapper creates fields with > > > the 'key' class method. > > > > > Do you think that HoboFields could be adapted to use MongoMapper? > > I don't know if there are migrations in mongoDB, or how they would work. > Certainly, there are indices. > > > As for the rest of Hobo, that's likely to be trickier; there's a lot of > > > messy code involving AR associations in things like auto_actions_for. > > > > > > In principle, it should be possible to split everything into three piles: > > > > > > - stuff that doesn't care about the ORM > > > > > > - stuff that cares, but only in generic ways that Hobofields / > ActiveModel > > > can provide an API for > > > > > > - stuff that is highly ORM-specific (hooking into AR associations, > > > generating migrations) > > > > > How much stuff in Hobo 1.3 is highly ORM-specific? Isn't part of the Rails3 > migration to get away from ORM-specific code? > > > But that's like saying "in principle, one can use classical mechanics to > > > predict the motion of every particle in a waterfall" - true, but the > > > details are a wee bit tricky... > > > > > > --Matt Jones > > Thanks for the feedback. It helps me in how I talk to my potential client. > Certainly I prefer Hobo over vanilla Rails, but I may need to fall back to > Rails because of the client's concern that relational databases will not > scale to volumes that are anticipating. > > Regards, > > Henry > > > -- > > Henry Baragar > > Instantiated Software > > -- > You received this message because you are subscribed to the Google Groups > "Hobo Users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<hobousers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/hobousers?hl=en. > -- - Owen Owen Dall, Chief Systems Architect Barquin International www.barquin.com Cell: 410-991-0811 -- You received this message because you are subscribed to the Google Groups "Hobo Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/hobousers?hl=en.
