From: Holden Glova <dsafari@...>
Date: 2002-09-03T09:48:30+09:00
Subject: Re: Idea: Ruby Object Persistence Service

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have never heard of DBize before, does this maintain mappings of collections 
for you as well? The holy grail is to not write SQL (or whatever you need to 
store persistently) for the majority of the cases.

On Tue, 03 Sep 2002 12:37, Tom Sawyer wrote:
> gabriel-
>
> admitedly i've only skim read this, but i'll go over it again in a bit.
>
> i know i've mentioned them before, so perhaps i'm missing something, but
> besides the caching i believe i am actually doing a good bit of this
> already, albiet far from complete (i'm dealing with other issues
> presently), with ONI and DBize. ONI is similar to SOAP but uses straight
> TCP/IP and YAML, while DBize is a mixin that automatically maps objects
> to a database. they both need some work, and you note a few things that
> may be nice addtions to them, but i am using both of these in my current
> project and they are working well thus far.
>
> -transami
>
> On Mon, 2002-09-02 at 16:21, Gabriel Emerson wrote:
> > I was just thinking last night of working on a TCP/IP server which would
> > create, restore, and save ruby objects to a Ruby DBI compatible database,
> > and optionally to a series of ruby hashes that would temporarily cache
> > objects in cases where that behavior would be desirable.
> >
> > What I was thinking of was a module that could be mixed in, would provide
> > the hooks into create, restore, and save, and would call a remote TCP/IP
> > server which would provide the functionality for handling these calls.
> >
> > The server would implement a socket listener which would receive
> > connections and then pass them off to separate stateful, reliable threads
> > which would handle the rest of the transaction.
> >
> > The mapping between RDBMS and object layer would be expressed in an XML
> > file, and would allow for two levels of object lookups.  The first would
> > be direct queries on the database, the default being an equality to an
> > OID generated by a global sequence (postgresql) or equivalent, or
> > equality to a field in the table corresponding to that object.  The
> > second would be lookups on the return values of attr_readers on the
> > objects, probably in some sort of objects.each.collect type of statement.
> >
> > For create, restore, and save, a boolean flag for whether or not the
> > cache could be consulted would be required.  The behavior of each action
> > would be different depending on the setting of this flag.
> >
> > The XML mapping file would be loaded along with the server.  At the same
> > time it would do a 'require' on each business object in question.  The
> > real win here is for web apps, which must 'require' these business
> > objects at run time, and even in the event of require caching due to
> > persistence owing to mod_ruby, new apache processes still must do these
> > 'requires' again.
> >
> > Upon object creation, a factory would set the @mapping hash on the
> > object, which it could carry with it.  A save or restore would consult
> > this mapping.  This is a big win again because objects creating these
> > mapped objects would not need to do their own 'require'.
> >
> > Restore would accept either a scalar which would be interpreted as the
> > special field OID (which would be included on all tables) or as a hash of
> > field name, operator, and value, expressed like "foo=" => 5, "bar<" => 3,
> > "baz=" => "alliwantforchristmasismytwofrontteeth"
> >
> > Without too much trouble, the persistence objects could probably also
> > allow for persistable collections, so long as the objects in those
> > collections are homogeneous and are themselves mapped by the xml mapping
> > file.  So an attribute of object Foo could be a list of objects of type
> > Baz, so long as Baz itself is mapped.
> >
> > The connection between the OPS client and the OPS server would be in the
> > form of a message stating the required action, followed by a
> > content-length, and then the serialized object, if these are appropriate.
> >
> > Having said all of this, does anyone have something similar, or are there
> > existing technologies I should use while implementing this, or have I
> > come up with a completely silly idea?
> >
> > Additional ideas include adding on a web-accessible monitor for the cache
> > and object creation, as well as perhaps a separate naming service.
> >
> > --Gabriel Emerson

- -- 
Signed,
Holden Glova
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9dAS+0X8w8X71zPcRAkP3AJ93GfPFE4M0JfECfxOCSJrGiAqAUACfUUtg
2/sDOpzuvMJk5ryQBVrJfiQ=
=34px
-----END PGP SIGNATURE-----