Forum: Ruby "Self Organizing Record" Idea

Posted by thunk (Guest)
on 2010-03-06 02:30
(Received via mailing list)
(and the real question on my mind lately...)

I'm using Class instances directly as "records"  and intend to use
CouchDB (or another "document" base) to pull them up when the system
gets larger.

Things are working out great with only 20 instances and we are saving
a lot of time versus anything else for now.

Recently I started thinking of other potential advantages of doing
this as we grow toward 400 or so records.

(The object returns an array of hashes for each methods that
correspond roughly to relational db "fields")

So, I have been starting to think about a scheme that would go
(basically) like this:

1.  a new instance method might be added to each class dynamically and/
or new instance data might be added to the class.

2.  the object is "marshaled" out with the new methods/variables/data

3. Now the class is reloaded  and it is "pretty printed" into a
readable format (less comments, I assume).

and whoalla...  the class will be "corrected" without being edited
directly.

This seems pretty "effective" (and a little too clever?) to me, I
haven't tested it yet , but with Ruby this stuff has usually worked
out for me so far..  any comments on this?

Thanks,

Thunk
Posted by David Masover (Guest)
on 2010-03-06 05:39
(Received via mailing list)
On Friday 05 March 2010 07:30:08 pm thunk wrote:
> (and the real question on my mind lately...)
> 
> I'm using Class instances directly as "records"  and intend to use
> CouchDB (or another "document" base)

I'd suggest Riak, but I haven't used any so far.

> to pull them up when the system
> gets larger.

Wait, Class instances?

...why?

I really don't understand this. Why would you create a brand-new class 
for
each record? I can understand creating a brand-new _object_ and 
extending it,
but a class?

> 1.  a new instance method might be added to each class dynamically and/
> or new instance data might be added to the class.

Again, it makes NO sense to create a new class for this. Let's talk 
actual
code. Are you really thinking something like this:

klass = Class.new
klass.send :define_method, :foo do
  # ...
end

If so, do this instead:

require 'metaid'
object = Object.new
object.meta_eval do
  define_method :foo do
    # ...
  end
end

> 2.  the object is "marshaled" out with the new methods/variables/data

Nope, marshal can't save methods -- or code blocks, as I understand it. 
You'd
have to store those methods as strings and run them with 'eval', which 
seems
tricky and dangerous.

> and whoalla...  the class will be "corrected" without being edited
> directly.

What do you mean "corrected"?
Posted by Brian Candler (candlerb)
on 2010-03-08 13:47
thunk wrote:
> Recently I started thinking of other potential advantages of doing
> this as we grow toward 400 or so records.

That still sounds like a pretty small system.

If your entire collection of objects can sit in RAM, have a look at 
"madeleine". This is a simple object persistence mechanism - a few 
hundred lines of code, simple enough to understand in its entirety. It 
marshals your graph of objects to disk, and can also do transaction logs 
for incremental changes.

Of course you won't get the HTTP API and replication which CouchDB gives 
you. CouchDB's incremental map-reduce is also awesome, but with 400 
objects, you can happily just do a linear scan :-)

Regards,

Brian.
Please log in before posting. Registration is free and takes only a minute.
Existing account (Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
No account? Register here.