Re: ODBA 1.0.2

Ruby
1

Hey Hannes,

Really interesting work, but I’m not sure, but your approach reminds me
of Og


Am Tuesday 07 February 2006 20:35 schrieb Hannes W.:
2

Hello,

this seems interesting. thanks for sharing it.

  1. from your response to an earlier question it seems that odba stores
    the
    data in a form which is not “interpreteable” by the underlying storage
    engine. for example, if the store is a sql database you won’t be able to
    write sql queries to search for objects with particular properties
    unless
    you read them from the database using your ruby layer. which means that
    when
    i need to search i have no choice but to read everything in to memory
    and
    then seach there. correct?

  2. how do you store the objects in the store? is it some kind of textual
    representation like xml?

thanks
konstantin

3

Hi Michael

Really interesting work, but I’m not sure, but your approach reminds me of Og

  • are you aware of that and could you give a short summary of the differences
    between them?
    you can find Og at HugeDomains.com

thanks, I had in fact heard of Og, but did not know exactly what it did.
I think the main difference between ODBA and any ORM (Object
Relational Mapping) - such as Og - is that ODBA isn’t really an ORM.
The main differences, as far as I can see are:

  • Where a good ORM will create and update a Database Schema according
    to the known mapped classes (and with a less automated one you have to
    do the job manually), ODBA does not change the database Schema, except
    when creating or dropping an index.
  • In a ORM, each attribute of an object needs to be stored in a Field
    with a defined and static Type. In ODBA, dynamic typing is preserved.

The reason for this is that ODBA stores entire Objects in a
deconnected and marshalled form, leveraging the strengths of whichever
Marshaller (I’ve tried Marshal and YAML) is used.
The Downside of this is obviously that using ODBA/Marshal and to a
lesser extent ODBA/YAML means subscribing to a lockin - i.e. not being
able to access the same data from a non-ruby application. And if
ad-hoc queries are needed, or data needs to be repaired manually etc.,
this can only be achieved through a ruby script (irb to the rescue!).

Did this answer your question?

All the best

Hannes

4

Hi Konstantin

On 2/7/06, konsu [email protected] wrote:

  1. from your response to an earlier question it seems that odba stores the
    data in a form which is not “interpreteable” by the underlying storage
    engine. for example, if the store is a sql database you won’t be able to
    write sql queries to search for objects with particular properties unless
    you read them from the database using your ruby layer. which means that when
    Correct.
    i need to search i have no choice but to read everything in to memory and
    then seach there. correct?
    This is true in principle. You can however define Indices that
    leverage the database engine’s
    search capabilities. I’ve put together some code-examples, in particular
    dev.ywesee.com - ODBA/ConditionIndex and
    dev.ywesee.com - ODBA/FulltextIndex
  1. how do you store the objects in the store? is it some kind of textual
    representation like xml?
    That depends on the Marshaller that is being used.
    The default is the ruby Marshal module, with the resulting binary
    string packed to base64 to prevent database interface errors.
    I’ve also successfully tested using YAML as the Marshaller. Basically
    any Object that supports load(String) and dump(Object) should work.

Cheers
Hannes