If a database has persistent data that comes from an aspect, what would it be? Examples of this would be design patterns implemented as an aspect, metadata about an object, or other data that is introduced by the aspect. Also, a data "feature" will change the way data is stored in the database. The feature of a "revision history" is implemented as an aspect of the persistent data. The feature changes the persistence of a regular object to contain the modification time, and the prior instances.
In order to access the revision history of an object that has the feature of versioning, an aspect query syntax is needed to provide access to the custom information. an example of a query that returns the sequence of instances that represent the change history of an object could be:
select aspect(Version) from Customer where customerId = "12345"
This would match against the customer extent finding the instance that has a customerId of 12345, and returns the result defined by the "Version" aspect. This could be an envelope containing the instance at the time of a modification, and the time modified as a collection.
The result of accessing an object redefined by a "Version" aspect will depend on it's context. The normal usage would be just like any other object access. But what if you want to access the view of the object at a prior point in time? The context time of the query can be modified and the same query that provides a normal object could return the value of the object at the context time. The query can be reusable accross different contexts with different meanings.
A RDBMS typically supports triggers that are procedures that are executed at certain events within the database. This is a very normal aspect oriented flow. So, an aspect oriented database would not run a trigger, but just advice at the certain event defined by the DBMS. Also, the design pattern of an observer can be implemented as an aspect that would introduce a relationship between the subject and observer. The modification of the subject sends events to the observer(s). This is the same pattern as a trigger, but in an AODBMS the paradigm of thought is advice and design patterns as reusable aspects.
Wednesday, February 28, 2007
Subscribe to:
Post Comments (Atom)
Labels
- agile (2)
- annotation (2)
- AOP (7)
- Aspect (1)
- AspectJ (4)
- concern (1)
- Context (1)
- database (2)
- DBMS (2)
- Design Patterns (1)
- Domain (1)
- domain model (1)
- DRY (1)
- DSL (1)
- Exceptions (1)
- grow (1)
- hibernate (1)
- Java (3)
- JAXB (1)
- JPA (2)
- OO (2)
- ORM (1)
- requirements (1)
- SME (1)
- software development (1)
No comments:
Post a Comment