I've found a couple of issues around annotations becoming orphaned due to the way they are stored. It looks like annotations are saved referencing the full URI of page, like http://annotate.localhost/node/1.

The issues I'm seeing are that if a URI changes (http://annotate.localhost/node/1 becomes http://annotate.localhost/blog/my-first-post), remain saved in the database but are inaccessible if accessing the node from a different URI, such as a path aliases.

Additionally, if node 1 is deleted from the system, it's annotation records persist even though it's gone forever from the system.

I like the power and flexibility storing annotations based on URI gives, but I think it might be better for it to be keyed to an entity_type (like a node) instead of to a URI, which can be altered in many ways.

If annotations are saved via URI, then then that means they're probably being loaded via URI as well. What are the pros and cons of keying saving/loading annotations to an entity rather than a URI?

Comments

molenick created an issue.

molenick’s picture

A simple demonstration to show how this would affect a common Drupal use case is:

1) Person posts a blog entry with a URL path alias/pathauto.
2) Other people annotate blog entry.
3) Person edits title/path alias - annotations are orphaned.

Also, I'm worried that annotations will also become orphaned if the text they're annotating changes. An annotation that no longer appears in the text could be detect by some pattern matching, but it might not be good to delete outright.

Also, I think the saving/loading of annotations should use a revisioning system (like for node) if it exists. I'm not 100% if the entity_api handles revisioning on its own.