From: Tom Sawyer Date: 2002-09-03T09:37:56+09:00 Subject: Re: Idea: Ruby Object Persistence Service --=-4+lYAGyQI37jKZqelFbM Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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=20 > create, restore, and save ruby objects to a Ruby DBI compatible database,= =20 > and optionally to a series of ruby hashes that would temporarily cache=20 > objects in cases where that behavior would be desirable. >=20 > What I was thinking of was a module that could be mixed in, would provide= =20 > the hooks into create, restore, and save, and would call a remote TCP/IP=20 > server which would provide the functionality for handling these calls. >=20 > The server would implement a socket listener which would receive connecti= ons=20 > and then pass them off to separate stateful, reliable threads which would= =20 > handle the rest of the transaction. =20 >=20 > The mapping between RDBMS and object layer would be expressed in an XML=20 > file, and would allow for two levels of object lookups. The first would = be=20 > direct queries on the database, the default being an equality to an OID=20 > generated by a global sequence (postgresql) or equivalent, or equality to= a=20 > field in the table corresponding to that object. The second would be=20 > lookups on the return values of attr_readers on the objects, probably in=20 > some sort of objects.each.collect type of statement. >=20 > For create, restore, and save, a boolean flag for whether or not the cach= e=20 > could be consulted would be required. The behavior of each action would = be=20 > different depending on the setting of this flag. =20 >=20 > The XML mapping file would be loaded along with the server. At the same=20 > time it would do a 'require' on each business object in question. The re= al=20 > win here is for web apps, which must 'require' these business objects at=20 > run time, and even in the event of require caching due to persistence owi= ng=20 > to mod_ruby, new apache processes still must do these 'requires' again. >=20 > Upon object creation, a factory would set the @mapping hash on the object= ,=20 > which it could carry with it. A save or restore would consult this=20 > mapping. This is a big win again because objects creating these mapped=20 > objects would not need to do their own 'require'. >=20 > Restore would accept either a scalar which would be interpreted as the=20 > special field OID (which would be included on all tables) or as a hash of= =20 > field name, operator, and value, expressed like "foo=3D" =3D> 5, "bar<" = =3D> 3,=20 > "baz=3D" =3D> "alliwantforchristmasismytwofrontteeth" >=20 > Without too much trouble, the persistence objects could probably also all= ow=20 > for persistable collections, so long as the objects in those collections=20 > are homogeneous and are themselves mapped by the xml mapping file. So an= =20 > attribute of object Foo could be a list of objects of type Baz, so long a= s=20 > Baz itself is mapped. >=20 > The connection between the OPS client and the OPS server would be in the=20 > form of a message stating the required action, followed by a=20 > content-length, and then the serialized object, if these are appropriate. >=20 > Having said all of this, does anyone have something similar, or are there= =20 > existing technologies I should use while implementing this, or have I com= e=20 > up with a completely silly idea? >=20 > Additional ideas include adding on a web-accessible monitor for the cache= =20 > and object creation, as well as perhaps a separate naming service. >=20 > --Gabriel Emerson >=20 --=20 tom sawyer, aka transami transami@transami.net --=-4+lYAGyQI37jKZqelFbM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9dAa6ITYvPhXYDikRAsTvAJ9+pfNFa18GidgR5k+dnBWCZv14UgCgg3Hb Tpb1pR3D3YAsSOgwwhcVs1c= =4M3t -----END PGP SIGNATURE----- --=-4+lYAGyQI37jKZqelFbM--