TNS Internal:Users/Endries

From NSDLWiki

Jump to: navigation, search

Internal place to put random stuff.

Contents

[hide]

NDR

Concepts

Annotations

Architecture Layers

The current organization has some relationships that are non-intuitive, if not confusing. For example: API calls accessing Fedora objects which run disseminators that call the API. Designing a well-defined layered scheme would help make usage and development easier. This may duplicate some code, but I think that is okay, because though the code may be similar the purpose it serves is different (and may diverge).

Transactional Model

Fedora does not provide a transactional interface. Since NDR 2 uses groups of objects as a single conceptual unit, operating on multiple objects "at once" would be helpful. This could be implemented using one or more methods:

  • Temporary object locking, perhaps via a timestamped property. Both the time and source (agent) should be specified. If the date is old, it's replaced/removed/ignored. If not, an error is returned referencing the locking application (and probably date, and/or time left).
  • Temporary objects; when you create a composite object, everything is created using temporary identifiers. Only after the transaction is complete does it get committed using the real values. If anything fails, the temporary objects can disappear or be modified, etc., and the data integrity of the system is not changed. One idea to implement this is a Transaction object to which you add() other objects, then call commit(). A Collection::commit() call or AddCollection API call, for example, could use this behind the scenes.

Concurrent Object Modification

Closely coupled with the transactional problem is that of concurrent modifications. If something else modifies an object you're modifying, you could overwrite those changes when you commit your object. This may already be implemented...I don't know. A seemingly simple way to do this would be store a hash of an object when you get it, and when you commit, pass in that hash. The back-end would make sure the stored object's hash matches what you pass in, and if so, modifies the object. If not, it returns an error. This may be mutually exclusive (or unnecessary) with the object locking idea.

Personal tools