#63 new
Yurii Rashkovskii

Consider refactoring multimetas approach

Reported by Yurii Rashkovskii | May 26th, 2008 @ 07:58 AM

So the idea is to get rid of multimetas approach we have so far. Why? The major reason is that current way allows you to define extra functionality, but not extra data.

Like, if you have Fruit and Product meta, and want to use them combined and if you want Product to have a price, you will need Fruit document have it anyway, like:

myfruit:
  name: Apple
  color: green
  price: $1

Which is basically might be ok, but... it is sorta controversial approach.

What I am thinking of is to make each meta act as a kind of trait in terms of both data and functionality.

So the idea is to organize a document in a kind of set of facets. I am not yet sure about the easiest way to organize this, but here is an idea to discuss

No meta specified:

  slot1: 1
  slot2: 2
  version: 1000...
  previous_version: 0000...

One meta specified:

 version: 1000...
 previous_version: 0000...
 Fruit:
    name: Apple
    color: green
 Product:
    price: $1

So basically document becomes just a little bit more complicated hash dictionary (one more level).

So, if you will treat the above document as just as Fruit, you will only jave slots name and color available, but when you'll "add" Product meta, you'll also have price.

The issue to implement a seamless API for that, with no/minimal hassles.

What do I want to have is being able to "concatenate" documents of different metas to combine them, either using existing #+ method or #<< :

apple_product = Product.new :price => 1
apple_fruit = Fruit.new :name => "Apple", :color => "green"
apple_fruit << apple_product

#<< looks a little bit more consistent because it shows which document should get new slots. #+ still can be used to generate new combined document.

Please not that with this given approach Meta metaslot will be gone, there will be no need in it... Well, I am not sure about it yet... how we'll distinguish usual metaslots and facets?

There are some issues with this approach, though.

For example, assigning new slots. It is trivial for single-meta documents, since they will go into that meta sub-hash. But what if we'll have multiple metas (as we intend to)?

apple_product = Product.new :price => 1
apple_fruit = Fruit.new :name => "Apple", :color => "green"
apple_fruit << apple_product
# Now it is both Fruit and Product
apple_fruit.description = "Awesome apple" # where should it go?

One of possible solutions is to put these slots to top-level, and if you want them to be assigned to some meta specifically, you might do as simple as:

apple_fruit[Product].description = "Awesome apple"

Another issue is that when you'll request a slot, Document will need to look it through all meta sub-hashes. Though Document can maintain a full list of slots with references to their metas to prevent extra computations.

Another issue is what if, say, two facets will have slots with equally named slots? That's trivial if one will access those slots with document[MetaFacet], but if with document[slotname] or document.slotname? Which slot should "win"?

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