Strokedb StrokeDB → 0.0.4

I was thinking about my data model in my old research project (Xi), where slots actually have no names but just a meta-document reference and reference to a "value" object and I just thought we can borrow some variation of this idea to be able to create truly meta-enabled databases.

So the idea is to enable Document#[Meta] API.

This will allow us to do things like:

person[PhoneNumber] = "6505555555"
person[FirstName] = "Yurii"
# ...
person[FirstName] #=> "Yurii" 
# and so on

This way will enable us to specify slots' meta-information in a very simple and consistent way.

The high-level implementation of it would be fascinately simple:

person[PhoneNumber] # in fact equals to...
person[PhoneNumber.document.uuid] 

Voila!

The another important question is since we have those meta modules with executable code attached, shouldn't we let slot values share them somehow? I think we should. Then legitimate question "how?" appears.

One of the possible ways is to let those slot values be hold in a kind of "utility" documents, so that

person[PhoneNumber] = "6505555555"

actually translates to

person[PhoneNumber] = PhoneNumber.new(:value => "6505555555")

While it is simple enough, there are several issues with it:

• PhoneNumber meta should support :value slot convention (or whatever we'll name it)
• we'll need to care about saving those PhoneNumber slot documents when host document is saved. That might be cumbersome
• we'll pay penalties of storing a lot more objects instead of simple values

We can improve this approach though. We can create immutable PhoneNumber instances but serialize actual value instead of these new documents. This way we'll have only one issue left (value slot convention) which is pretty much fine (at least for me).

Though at some point while scaling from a pure prototype to a large volume database, one may want to "extract" those PhoneNumbers to a separate documents for some reason (may be faster indexing or something like that). And still I don't think it would be a great problem ever. Those who will want to perform such kind of migration would want to execute following steps:

• declare persistent metaslot within host document's meta
• go through existing documents and literally re-save them.

What's that persistent metaslot declaration is? I think it should be as simple as:

Person = Meta.new do
  persistent_metaslots :phone_number # or PhoneNumber
end

it probably should add a before_save callback that ensures those metaslots' persistence as a documents.

There is also a sort of small problem with persistent metaslots. Once you change PhoneNumber value, you might think you'll get new document. But that's probably can be easily avoided with doing #update_slots(:value => ...) instead of #new if you have this metaslot document associated already.

Thoughts?

P.S. And here is a bonus idea. For the convenience, we can have a slotname->Meta mapping API, just like this:

Person = Meta.new do
  metaslots :phone => PhoneNumber
end
PhoneNumber = Meta.new do
...
end
person = Person.new
person.phone # => this will be translated to person[PhoneNumber]

Hope that's sweet enough.