jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Waschkowski" <mwaschkow...@gmail.com>
Subject Re: DM Rule #5: References considered harmful.
Date Tue, 10 Jul 2007 17:42:23 GMT
Hi David,

Thanks again for initiating this discussion through your posts, its just
excellent.

I was about to respond in the other thread about same name siblings, but
there are a lot of posts in that thread and my comment seems more suited to
this thread. However, I found the below (from the other thread) to be most
helpful:

"I think it is important to look at (a) a meaningful path that is
explanatory of the context that you are in and (b) stable and unique
identification as two totally separate issues."

I really like the idea of modeling contacts like (which is different that I
originally planned ie. SNS):
/contacts/david@ day.com
/contacts/dev@ jackrabbit.apache.org

This is simple, and has meaning. However, if the repository is used (at
least in part) to replace some database type functionality, then dangling
references are unacceptable. I believe the following is a use case for
needing stable identification:

User stores a bunch of contacts
User stores a bunch of buildings
User wants to link each building to a contact.
User wants to link reports to a contact.
User wants to link 'x' to a contact.

Different buildings may want to refer to same contact. In future, other
entities may also want to refer to contacts. Of course, we don't want to
link contacts to other things as we shouldn't have to touch a contact when
adding other entities to the system.

Therefore, I would think that it would make sense for the contacts to have a
uuid, and everything else (in this case buildings, but there could be many
other entities that need to refer to a contact) refer to the contact by the
uuid. Then, if the contact's email address changed, that particular node
could be moved, but its uuid wouldn't change so all the references would
remain intact. I believe that using a path and then having to refactor all
nodes that refer to the contact by its path would be error prone.

Thus, it seems to me that you get both a semantic path for the contact, and
the benefits of referential integrity when needed, without worrying about
error prone refactoring. What do you think?

Best,

Mark

On 7/10/07, David Nuescheler < david.nuescheler@gmail.com > wrote:
>
> Hi Mark,
>
> Thanks a lot for your comment.
>
> > /contacts/johndoe
> > /contacts/janedoe
> > etc.
> > Maybe just using
> > /contact/contact[1]
> > /contact/contact[2]
> > and using uuid's to reference individuals make sense for this?
>
> I think it is important to look at (a) a meaningful path that is
> explanatory of the context that you are in and (b) stable and unique
> identification as two totally separate issues.
>
> (a) Meaningful Path
> ------
> [which really belongs into the "drive your hierarchy" section]
>
> I mainly use SNS as a symptom to diagnose a hierarchy issue
> in a content model.
>
> People use SNS mostly for large, unordered collections,
> which it is definitely not what they are designed for.
>
> [note to self: propose a better way to address this problem in jsr-283]
>
> SNS means that if you for example remove contact[1] the
> paths of all other contacts and all their children will need to
> change.
>
> Keep in mind that you force the repository to keep track of the
> order of your contacts. Which you are actually not interested in
> I would assume.
>
> While I think that...
>
> /contacts/0
> /contacts/1
> /contacts/2
> /contacts/3
>
> ... is better from that perspective, since the repository does not
> need to keep track of sort order and you get better path stability,
>
> I would still try something like...
>
> /contacts/david@day.com
> /contacts/dev@ jackrabbit.apache.org
>
> ...which could be both meaningful and unique.
>
> The reason for that is that someone who browses the repository
> with any form of generic application ...
>
> (like http://jsr170tools.day.com/crx/browser/index.jsp )
>
> ... understands get a meaningful list of contacts and
> the path reveals information about the context of the
> information.
>
> Let's assume the path should ever surface, for example in a URL,
> then...
>
> /contacts/mark@gmail/ituneslibrary/Nelly Furtado/Loose/Say It Right
>
> will give the user much more context than ...
>
> /contacts/contact[42342]/ituneslib/artist[234]/album[2]/track[8]
>
> ..and really, i cannot see a drawback for naming
> nodes in a meaningful way. ;)
>
> ---------
> (b) Stable and Unique Identification
> ----
> If your contacts should be mix:referenceable and therefore expose
> a UUID so they can be referenced in my mind is decided by
> the needs of you application.
>
> If you application needs to reference users in a stable fashion and
> you don't have something like a unique stable user-id (eg. an email
> or a login...) mix:referenceable certainly would be the way to go.
>
> (Important: this does not mean that a hard reference property
> needs to be used to refer to or identify the node later)
>
> -----
>
> Please keep in mind, this is just how I would model the content,
> and I am convinced that someone could possibly come up with
> a usecase where even I would warm up to the idea of using SNS... ;)
>
> regards,
> david
>



-- 
Best,

Mark Waschkowski

On 7/10/07, David Nuescheler <david.nuescheler@gmail.com > wrote:
>
> Hi Mark,
>
> > What about when the repository is being used instead of a database?
> > User stores a bunch of contacts
> > User stores a bunch of buildings
> > User wants to link each building to a contact. Different buildings may
> want
> > to refer to same contact.
>
> From my gut feeling I would recommend something like...
>
> /buildings/mainbuilding
> /buildings/th14
> /buildings/th5
>
> and
>
> /contacts/jack
> /contacts/joe
> /contacts/jill
>
> where the contacts have a multivalue "name"
> property called "buildings" containing strings like "mainbuilding",
> "th14", ...
>
> This is working off the assumption that the buildings are more
> static/stable than contacts. So I would choose the "link" pointing
> to the buildings.
>
> The reason why I chose a "name" property rather than a "reference"
> is really because I think the application could gracefully fail a dangling
>
> link to a building and because i think that the list of buildings is
> very static.
> Opposed to a "uuid" stuck in a reference the string "mainbuilding" will
> mean something to someone looking at it.
>
> > Isn't this a perfect use case for using a reference?
> If your application cannot afford dangling references and
> the building names are dynamic I would employ references.
>
> I think it is important to think about the other options
> that a content repository offers to link content before defaulting
> to the most rigid and expensive one (which is a reference).
>
> regards,
> david
>



-- 
Best,

Mark Waschkowski

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message