#15 ✓resolved
Yurii Rashkovskii

Figure out how to organize views for associations

Reported by Yurii Rashkovskii | April 28th, 2008 @ 09:39 AM | in 0.0.3

The idea is to allow unnamed views. They should be quite useful for associations, something like

User = Meta.new
  has_many :items

produces following meta document:

 // ...
 name: User,
 has_many_items: @#<reference to View document>
 // ... 

and View document is as follows:

 // ...
 meta: @#<reference to View meta>,
 reference_slotname: 'user', 
 meta: 'Item'
 // ...


Of course, we will address some edge cases to prevent spoiling databases with similar views — but that is rather optimization approach, so should be figured out a bit later.

Comments and changes to this ticket

  • Oleg Andreev

    Oleg Andreev April 28th, 2008 @ 11:21 AM

    I think things get easier when you do name a view like "has_many_{items}" or "{container}_has_many_{items}".

    If we'd like to put all the "has_many" assocs into the very same View, we would do a generic "has_many_view" view with a key [ doc.belongs_to, "comment"|"whatever" ], so that items can be using a suffix. And also, we have to provide some useful aliasing for belongs_to to use comments.article instead of comments.belongs_to

  • Yurii Rashkovskii

    Yurii Rashkovskii April 28th, 2008 @ 11:19 AM

    Please note that "{container}_has_many_{items}" will need to include nsurls for both container and items as well. Is that fine?

  • Oleg Andreev

    Oleg Andreev April 28th, 2008 @ 11:30 AM

    There is no need in nslurl for container: it is identified by UUID in a key.

    For The Very Generic Has Many View, yes, we have to put a meta name along with its nsurl. So i would like not to try to put everything in a single big list, but to have a common view for the different containers and a particular association. Like "has_many_comments" view for comments (attached to any kind of container).

    It is not really a problem to have some views duplicated. It is hidden under the has_many macro, anyway. But when you'd like to optimize some of the views, you may rebuild only one has_many view without affecting others.

    My suggestion is to have views being specific for an association meta, but generic across all the assoc's containers.

  • Yurii Rashkovskii

    Yurii Rashkovskii April 28th, 2008 @ 11:52 AM

    • Title changed from “Consider allowing unnamed views” to “Figure out how to organize views for associations”

    The picture you're trying to describe is not clear for me.

    Here is an attempt to summarize:

    Lets say we have a view for all has_many associations:

    (the code below is just a sketch):

    # View for documents that have associations
    docs_with_assocs = View.define("DocumentsWithAssociations") do |view|
      def view.map(uuid, doc)
            r = doc.meta.slotnames.grep(/^has_many_/).map do |assoc_slotname|
                  # emit pair with reference_slotname, meta and doc
            r.empty? ? nil : r
    # Views for associations
    View.define("HasManyAssociations") do |view|
       def view.map(uuid, doc)
             doc.slotnames.map |slotname|
                docs_with_assocs.find(:key => [slotname, doc.meta])
                # emit pairs for those documents that has appropriate associations defined in docs_with_assocs

    Something like that or not?

  • Yurii Rashkovskii

    Yurii Rashkovskii April 28th, 2008 @ 11:58 AM

    One of my concerns is that having N views to execute on each index update for N associations defined within database might be PIA

  • Yurii Rashkovskii

    Yurii Rashkovskii April 28th, 2008 @ 12:00 PM

    // #14 had some useful code snippet but was resolved as duplicate for this ticket

  • Oleg Andreev

    Oleg Andreev April 28th, 2008 @ 12:20 PM

    1) By default, yes, a document will go through all the views. This can be optimized by describing a filtering view (or a list of views) which emits a list of relevant views for a particular document. See "PERSISTANCE & UPDATES" section of meta/papers/views.txt.

    We may describe a scope of the view in several places: in a store setup, in a meta (see below) or the view itself. Depends on real situations we'll meet soon.

    2) View naming issue: we may add a nsurl to a view name.


    Article = Meta.new ... has_many :comments, :nsurl => "blah-blah"
    BlogPost = Meta.new ... has_many :comments
    # generates => 
    View.define("has_many:Comment:http://ns.url") do 
    Comment = Meta.new do
      update_views do |comment| # special callback on save to get a list of views to be updated
    # view can be added to update_views callback this way:
    # Comment.update_views << View["some_name"]
  • Yurii Rashkovskii

    Yurii Rashkovskii April 28th, 2008 @ 12:38 PM

    • State changed from “new” to “resolved”

    Whatever. Lets see how all this crap will work.

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

People watching this ticket


Referenced by