Strokedb StrokeDB → 0.0.3

Comments and changes to this ticket

• 

  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 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 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 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
          end
          r.empty? ? nil : r
    end
  end
  
  # 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
           end
     end
  end
  

  Something like that or not?

• 

  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 April 28th, 2008 @ 12:00 PM

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

• 

  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.

  Like:

  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 
    ...
  end
  
  Comment = Meta.new do
    update_views do |comment| # special callback on save to get a list of views to be updated
      Views["has_many:Comment:http://ns.url"]
    end
  end
  
  # view can be added to update_views callback this way:
  # Comment.update_views << View["some_name"]
  
  

• 

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

  • State changed from “new” to “resolved”

  Whatever. Lets see how all this crap will work.