David, 

thanks for the reply.  I started down that path.  

RHS is an entity itself.  Its state changes over time, with Identity 
independent of its relationships, it can be related to many entities (LHS). 
 So its state has to live in one place or employ synchronization (complex 
watchers?).  I remember seeing a reference to zipper functionality that 
seemed to imply a possible solution, I'll try to find that again..

Thanks,

Robert





On Tuesday, February 25, 2014 10:26:30 AM UTC-5, David Della Costa wrote:
>
> Is there no way to simply structure the maps inside your main atom in 
> such a way that you can look up your entities? 
>
> {lhs-uuid1 {rhs-uuid1 ["values"] rhs-uuid2 ["values"]}} 
>
> (get-in @myatom [lhs-uuid1 rhs-uuid2]) 
>
> You can wrap this in a function that does some other work to look it up 
> if need be, if the result of the above is nil (for example)...etc. 
>
> Seems like you're making things more complicated than they need to be 
> here, but it's hard to know without knowing more about your data. 
>
> But if I were you I would start there, as I've found thinking hard about 
> the structure of your data and and using the facilities provided by the 
> standard library usually helps simplify things tremendously. 
>
> (2014/02/25 23:14), Robert Quinn wrote: 
> > new to clojure, in the process of unlearning years of OO.  sorry for the 
> > long post. 
> > 
> > struggling with a design/impl and hoping to get some outside opinions so 
> > I can understand my options (clojure better) 
> > 
> > basic concepts are straightforward and in a nutshell I'm modeling 
> > entities and relationships  (aren't we all) 
> > 
> > --- 
> > 
> > created a pool of entities (people and groups) implemented as maps. 
> >  each map has a :rels which is set of relationships to other entities. 
> >  the pool is an atom. 
> > 
> > first approach; relationships are in the entity, add RHS entities into 
> > the LHS :rels.  the state of the RHS can change, I need the latest state 
> > of RHS not as it was when the relationship was created. I decided not to 
> > make each entity a ref (ref, atom, agent), it seemed too fine grained. 
> > *thoughts?* 
> > 
> > each entity has a uuid 
> > 
> > second approach, a pool of relationships (:lhs uuid :rhs uuid :type x). 
> > pool has all the relationships, also an atom.  the pool has lots of 
> > benefits it "improves" other parts of the code. 
> > 
> > it doesn't solve the original problem, just moves it around, i still 
> > can't put the actual RHS, so i'm using the uuid as a reference, i look 
> > up RHS get the latest. (second guessing why didn't i make them atoms and 
> > use @uuid). 
> > 
> > now my relationships aren't embedded in my entity, that doesn't feel 
> > right, anyone dealing with the entity should still be able to say... 
> > (:rels entity) and get the relationships, so i add a function to :rels 
> > that returns all the relationship based on the uuid of the LHS, this 
> > works great. syntax changes and requires me to use ((:rels entity)). 
> > 
> > *the problem is... (assumes everything within a single process)* 
> > 
> > I want to pass this data structure around and now dereferencing is 
> > bleeding out.  Instead of passing around a data structure, I'm passing 
> > around a data structure that has functions embedded in it.  which seems 
> > like a cool idea, but now the callee needs to know that :rels returns a 
> > function, when it's supposed to have data in it. (which is the same 
> > thing?) but I don't know how to treat it seamlessly.  (i have not 
> > considered eval). 
> > 
> > for the :rels it's not too bad.  doesn't feel like I'm using all the 
> > power correctly, but it works. 
> > 
> > *additional problem is, my rels look like this.* 
> > 
> > (:lhs uuid :rhs uuid :type x) 
> > 
> >  :lhs and :rhs "should be" entities, not references.  more functions?  I 
> > make :lhs and :rhs return functions which dereference entities. of 
> > course that makes selecting from rel-pool much harder 
> > 
> > that's when I knew I had to seek professional help (smile) 
> > 
> > even with a long post hard to capture all the requirements... 
> > 
> >  1. the pools aren't supposed to be "public" so I can't have all the 
> >     callee functions understanding how to do the dereference.   
> >  2. the :rels function isn't one function, the truth is the rels-pool 
> >     doesn't have all relationships, some are virtual, the function 
> >     creates them on the fly, each entity could have it's own version of 
> >     "get-relationships" 
> > 
> > any help is appreciated. 
> > 
> > i've considered 
> > 
> >   * creating a function that "denormalizes" the data before sending it 
> >     out to.  now its fully formed but i lose some recency (not much diff 
> >     i know) 
> >   * centralizing all the derefs functions - so the callee knows that all 
> >     the data isn't embedded but the functions don't live in structure, 
> >     just the uuids... that works well for LHS/RHS deref, but makes the 
> >     per entity virtual relationships much harder.   
> >   * rethinking my atom granularity and using @ but i don't think that 
> >     really helps 
> > 
> > 
> > thanks for reading 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com<javascript:> 
> > Note that posts from new members are moderated - please be patient with 
> > your first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com <javascript:> 
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> > an email to clojure+u...@googlegroups.com <javascript:>. 
> > For more options, visit https://groups.google.com/groups/opt_out. 
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to