#52 open
Yurii Rashkovskii

Consider adding Document#[Meta] API

Reported by Yurii Rashkovskii | May 10th, 2008 @ 02:58 AM | in 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.

Comments and changes to this ticket

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

StrokeDB is an embeddable distributed document database written in Ruby

Shared Ticket Bins