On Apr 16, 2007, at 12:22 PM, John Siracusa wrote:
>
> How about "object_tree" instead of just "object" to better indicate
> that
> input/output isn't just a long object:
>
> $yaml = $o->object_tree_as_yaml;
> $o->init_with_yaml_object_tree($yaml);
>
> Actually, depending on how you plan to encode things, it may be more
> appropriate to take this approach in the second example:
>
> $o = object_tree_from_yaml($yaml);
>
> so you no longer need to know the class of the tree root.
i'll use both suggestions.
i've started work on:
object_tree_as_yaml
object_tree_from_yaml
each object layer has a ".rdbo" entry for storing class data and rose
specific info
i've also started playing around with something that will make you
cringe, or perhaps chime in with suggestions and enthusiasm !
object_tree_as_storable
object_tree_from_storable
right now they're being made traverse the object tree and clear/
restore the db items + __xrdbopriv_meta
but i've got a much crazier idea--
i ideally want the getter/setter to handle everything in an internal
namespace , and have all the rdbo private stuff in its own namespace
as well
$object->{'data'}
where rdbo stores col data
$object->{'__xrdbopriv_obj'}
object specific data
__xrdbopriv_in_db
__xrdbopriv_is_verified_formattedpg
__xrdbopriv_timestamp_lastlogin_formattedpg
__xrdbopriv_rdbo_version= $Rose::DB::Object::Version
__xrdbopriv_class_version= md5( deep sorted list of
__xrdbopriv_meta computed once on startup)
etc
$object->{'__xrdbopriv_meta'}
stays the same
$object->{'__xrdbopriv_db'}
new name for the database
what i'd then like to do, is then have object_tree_from_storable /
as_storable create a new tree of objects based on the naemespaces
data and __xrdbopriv_obj -- __xrdbopriv_meta and db would be
automatically dropped when going into the storable format ( meta is
class specific, db is instance specific ).
then, when creating the objects from storable, $method( $data) would
not need to be called on every field ( which is what from_yaml does )
-- the object would just reference or be replaced by the appropriate
nodes in the deserialized object -- so long as we're reading from the
same rdbo and class versions.
the point of all this is to create cachable objects that are as-
small-as-possible when they go into memory, yet have almost no
overhead to revive.
its rather a large request for restructuring rose for this task --
but when dealing the object_tree_from_storable I'm noticing a bit of
a load in overhead when dealing with a lot of rows and objects.
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| SyndiClick.com
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Rose-db-object mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rose-db-object
