Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

Consider adding Document#[Meta] API

#52

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.

Reported by Yurii Rashkovskii · May 9th, 2008 @ 11:58 PM

State: open
Milestone: 0.0.4
Assigned to: Yurii Rashkovskii Yurii Rashkovskii

Activity

  1. Yurii Rashkovskii
    Yurii Rashkovskii
    • Assigned user changed from Oleg Andreev to Yurii Rashkovskii

    May 9th, 2008 @ 11:47 PM

  2. Yurii Rashkovskii
    Yurii Rashkovskii

    I would like to emphasize that it seems that implementation of this feature will not be that complex. We seem to have all or most of all building blocks for this; and it will NOT replace #[:slotname] or #slotname API — it will be just an option on top of it.

    May 9th, 2008 @ 11:54 PM

  3. ronin-14694 (at lighthouseapp)
    ronin-14694 (at lighthouseapp)

    +1 I really like this idea. It would allow for some great object modelling, where a slot Meta document contains further logic. I guess it means that you can create a slot Meta for a common datatype (like PhoneNumber) and set formatting/validation logic there if I gather correctly.

    May 10th, 2008 @ 10:08 AM

  4. Yurii Rashkovskii
    Yurii Rashkovskii

    Fabien, you are absolutely correct — you can extract common datatypes of literally any level of complexity and set formatting/validation logic there; not to mention that your documents' slots with these metas (aka metaslots) will now have "machine-readable meaning"

    May 10th, 2008 @ 10:23 AM

  5. Yurii Rashkovskii
  6. Yurii Rashkovskii
    Yurii Rashkovskii
    • State changed from new to open

    May 14th, 2008 @ 02:34 AM

  7. Yurii Rashkovskii
    Yurii Rashkovskii

    Agreed to separate [by design] left side (metaslots) and right part (document embedding). That will provide a better flexibility for us.

    May 15th, 2008 @ 03:18 PM

  8. Yurii Rashkovskii
    Yurii Rashkovskii

    So in this ticket we'll deal with left side only.

    Here is what's left:

    • consider moving special slots like meta, version, previous_version to metaslots

    May 17th, 2008 @ 07:04 PM

  9. Yurii Rashkovskii
    Yurii Rashkovskii

    :meta has been replaced with Meta metaslot

    May 25th, 2008 @ 07:31 AM

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.