On Fri, 26 Sep 2008, Bluebie, Jenna wrote:
> Maybe one of those modern ORM's that create the tables from your classes
I thought they wanted the tables for display....
> rather than the other way around would be better for shoes. It's unlikely
> shoes will be in a situation where it has to bend to the existing design of an
> SQL server. I don't remember the name of any of those new age ORM's though.
> Could be nifty to just write a class and have data magically be stored
> permanently... like a persistent object.
>
> Woah, now hold on a second, is that a far better idea?
>
> Could we 'include Persistence' in to (maybe singleton) classes in shoes, and
> have them define a starting state in the initialize method and then when the
> app closes, be serialized in to some place, and when launched, recreated (via
> allocate, not new, avoiding initialize) and be exactly how they were left? Yay
> or Neigh?
Not sure. Would you need it to be singleton? I'd have thought the
whole point of a class defining a db table is to allow several
instances to be stored in that table.
>
> It would create a funky illusion that the class had never actually
> disappeared, and that it was still the exact same class as the last time you
> ran the app. Well, except for that pesky object_id, and the way it would
> explode if you tried to store an unserializable object in it. :)
What happens if you dRB to a server that just stores a blob for the object
you prod it with? I've not done stuff with DRuby for ... several years
so I am a bit -- a lot rusty.
Otherwise it should be possible, if you just want to store the class to
use reflection.
I'm thinking out loud^H^H^H^Hmumble here, probably at cross purposes to
you both.
Hugh
