Support cardinality/many

[avescodes]

I wanted to start a conversation about cardinality/many.

I have a number of thoughts about meshing Ruby/ActiveRecord idioms with Datomics implementation. The most pressing is Datomic's usage of sets (if I'm not mistaken) as opposed to ActiveRecord heavily utilizing ordered and non-unique arrays.

I think it is probably sanest to stay as close to actual datastore implementation as possible. So I'll probably approach this via Set. This may be a little jarring for less Clojure-y developers coming to Datomic, so I think it might be worthwhile to keep the API users informed by complaining early (e.g. you try to assign an array as a default instead of a set).

Next up is retraction/protraction scheme. I think if the set-based approach is used this becomes a simple matter of producing a list of retractions and protractions based upon the difference between original and present values.

[cndreisbach]

I agree with this, except for one point: I think we should be as permissive as possible. Since there is no literal syntax for sets in Ruby, allowing people to pass arrays as defaults (or maybe even assigning directly to the attribute) seems like the nice thing to do.

After typing that, I realized that the behavior might be confusing to people, though. Hmm. Maybe we start by implementing sets and then, if that is painful to use, we consider being more permissive.

[yokolet]

I've start looking at this issue. I understood how datomic's cardinality would work. There's huge difference between Ruby data model and datomic.

In Ruby side, sets is a reasonable. We can use http://www.ruby-doc.org/stdlib-1.9.3/libdoc/set/rdoc/Set.html for that. The should-have methods would be 9 listed in the top of http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html .

In datomic side, cardinality always expresses relations between entities. So, assuming the following entity is defined in Ruby side:

class Person
  include Diametric::Entity
  include Diametric::Persistence::Peer

  attribute :name, String, :index => true
  attribute :emails, String, :cardinality => :many
end

each email entities should have a reference to its owner entity (Person?) when created.

[avescodes]

Hey. Can't talk too long, but I'm working through this at the moment. I have a half done implementation that I'm trying to wrap up before Monday. I'm working on client work tomorrow, but I'll see if we can connect to at least sync up.

Ryan Neufeld

On Thursday, November 8, 2012 at 10:34 PM, Yoko Harada wrote:

I've start looking at this issue. I understood how datomic's cardinality would work. There's huge difference between Ruby data model and datomic. In Ruby side, sets is a reasonable. We can use http://www.ruby-doc.org/stdlib-1.9.3/libdoc/set/rdoc/Set.html for that. The should-have methods would be 9 listed in the top of http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html . In datomic side, cardinality always expresses relations between entities. So, assuming the following entity is defined in Ruby side, class Person include Diametric::Entity include Diametric::Persistence::Peer attribute :name, String, :index => true attribute :emails, String, :cardinality => :many end

we need to create email entity definition internally. When a instance(entity) of Person class is created, email entity must be created internally and should have dbid of Person instance.

— Reply to this email directly or view it on GitHub (https://github.com/crnixon/diametric/issues/3#issuecomment-10214598).