AVM and associations

[bartr]

Hi,

I really love the concepts of layering and sandboxes in the AVM and I'm moving a repository previously created in the non-AVM repository to AVM. (I need multiple 'published' publications that are activated at a given time in the future, and sandboxes seem to be the ideal vehicle for this).

One problem in migrating content between the two stores: in the AVM store it is no longer possible to create 'normal' associations between nodes. I am wondering whether you intend to implement this at a later stage or whether you don't think it's feasible to do so in view of the complexities of 'layered associations'?

I'm currently working around this with multivalued noderefs, but I don't think they're really intended to be used as a replacement for associations (one major problem is that they are really stored as blobs, without the possibility to enforce referential integrity).

Any other suggestions for creating non-parent-child associations in AVM?

Thanks,

Bart

[britt]

Hi,

I really love the concepts of layering and sandboxes in the AVM and I'm moving a repository previously created in the non-AVM repository to AVM. (I need multiple 'published' publications that are activated at a given time in the future, and sandboxes seem to be the ideal vehicle for this).

One problem in migrating content between the two stores: in the AVM store it is no longer possible to create 'normal' associations between nodes. I am wondering whether you intend to implement this at a later stage or whether you don't think it's feasible to do so in view of the complexities of 'layered associations'?

I'm currently working around this with multivalued noderefs, but I don't think they're really intended to be used as a replacement for associations (one major problem is that they are really stored as blobs, without the possibility to enforce referential integrity).

Any other suggestions for creating non-parent-child associations in AVM?

Thanks,

Bart

Hi Bart,

Here's what I can tell you. I'm working on it.  Actually we're working on it.  Associations cannot be implemented for the AVM repository in the same way they are in the core repository because the two repositories have a few fundamental semantic incompatibilities.  Mostly these are a consequence of the AVM's versioning, branching, and layering capabilities.  In practical terms associations in the core repository are direct node to node relations.  Such direct node-node associations applied to the AVM would not have the same semantic meaning, and would be mostly useless.  In the AVM world the semantically equivalent construct would be node reference to node reference associations.  So that is what we plan to implement.  Conceptually it's a fairly simple addition to the AVM.  In practical terms it's going to be a bit tricky because node references in the AVM are not simple database primary keys but rather path/version combinations.

We will get there; it's just going to take a little time to do it right.

[britt]

Hi Bart,

I forgot to add that multivalued properties are indeed the only existing approximation to fully general associations in the AVM that I've been able to think of.

Cheers,

[jcox]

Thanks for the great feedback.
I had some comments regarding your use case:

I really love the concepts of layering and sandboxes in the AVM and I'm moving a repository previously created in the non-AVM repository to AVM. (I need multiple 'published' publications that are activated at a given time in the future, and sandboxes seem to be the ideal vehicle for this).

Using layers to create "future" versions of staging is a very powerful technique, but be careful of the  Golden Hammer antipattern….   If your future version of staging is structured in a similar manner to the "main" staging area, then a layer or two (or three) might be a nice way to go;  if not, create a branch.   Once you get over a handful of layers stacked on top of each other, performance might suffer a bit, and users might get confused about what's coming from where… so use layers with this in mind.

Here's a rule of thumb:  layers are best when you're expressing converging deltas in content  (not profound structural/organizational differences);  thus, if you're planning an elaborate setup, avoid relying on tall "Leaning Tower of Pizza" structures, and favor smaller stacks &  multiple branches held together with workflow.

[bartr]

Britt and Jon,

Thanks for your elaborate answers.

It's good news to hear associations will be introduced in the avm - the noderef-workaround is bound to break at some point. I'm not sure whether I understand the implementation you envisage; for what it's worth, my idea would be that
* associations themselves are versioned/layered, so it would be possible to define or alter an association in one sandbox without any consequences to other sandboxes.
* the parent- and child-nodereferences of an association are stored store- and version-independently, but are resolved to the store and latest-version (-1) through which they were accessed when they are returned from the services-layer. This allows associations to be promoted without any changes from one sandbox to another and ensures the references are always taking all aspects of the layer in regard.
This approach obviously doesn't allow one to create an association from or to a specific version; I'm not sure whether such a versioned-association would be useful, but if need be, they could still be stored with the store- and version information and a little flag indicating this info should be retained (this could flag could even be different for each end of the associaion: e.g. the parent-side can be set to versioned, while the children are not, indicating that a given version did contain these children, while another version has a different set of children; only the last version of the children is of interest to the association.)

(Just hoping this is useful user-input, not trying to impose my views)

I take the layering/branching advice into account; the changes will be restricted to metadata-changes and small structural changes (new directories and files might be added), but no relocations or deletions, so I'll go ahead with the layered sandboxes for now.


Thanks again for your help,

Bart

[jcox]

Bart,

Deletions in a transparent layer are OK. 
The layer below is not altered (unless you submit the deletion).

The detailed operational semantics of layers can be found on the Transparent Layers wiki page… but please don't take the pukey color scheme & ugly symbols literally. This is an in-depth look at corner cases;  I wasn't focusing on beauty.  The next generation GUI will be much prettier, and will allow some amount of  control over how much of this low-level detail is exposed.  Right now, all GUI can do is show which items have been "modified".  Therefore, it's probably best to think of the Transparent Layers  page as just the "geek's eye view" of the system, and no more.

It's also important to note that casual users will/should never need to know all this stuff, because workflow can automate things like clearing away modifications after a successful submit, etc.  Casual users spend most of their time in wizards anyhow, not the "tree" view of the repository structure; therefore, subtle distinctions don't arise for them.  For example, casual users will typically just get a well-defined batch of files to work on in a task, some data input fields/forms, a submit button, and that's it.