How Important is Symmetry in JPA?

When you are designing a domain model using JPA or hibernate or another declarative approach to ORM, you must decide the cascade rules for creating and deletign objects that are related to each other. When you have a one-to-many relationship between two objects, when an object is persisted, you need to decide if the related object should be automatically persisted as well, or should you have to persist each object?
To me it seems that this must be made symmetrical, that is if you cascade create, then you should cascade delete as well. Any other rule than this makes your system more complicated. Intuition should be available to one trying to understand your domain model, and symmetry is a part of nature, so it will be intuitive to expect a consistent behavior. If you are using JPA, the cascade rules will be in the code so you will see the rule with the code so it will be evident of your choice. In the case that you are using Hibernate from an XML configuration file that is not visible at the same time as the source code, then you will have to remember the cascade rules, minimizing the burden of memorizing too many things can help in comprehending your model, a consistent rule of always cascade create with delete will eliminate this from your efforts.
In a more encapsulated direct approach, I recommend that a new annotation of @Aggregation be created that has this behavior as it's meaning, it is simple and precise as to the intent. AspectJ can be used to create this annotation, and with JPA annotations as the ORM approach, the needed annotations can be injected behind the scenes. This seems like a nice clean use of AOP to help in using of JPA.

Is-a vs. has-a

When you model your system in object oriented methodologies, you have to choose whether a class "is-a" a certain type or if it "has-a" a certain type. Is this confusing? The best way to think of this is to ask what is a customer? If you have a class "Person" in your model, then you might think that a "Customer" is-a "Person". But that starts to get complicated. A customer is someone who has bought a certain product. So, can you scale the is-a version of customer to purchasing of multiple products? Maybe you can model a customer as an order that has been fulfilled, and a person can have a collection of orders, thus a person "has-a" collection of orders. But many situations involving two different products do not occur at the same time usually, so you would preferr to just treat the person as a customer while in the situation involving a certain product.
Then you could have the best of both worlds. But what system or languatge can handle this? You would always have to have some sort of layering and pretend that the other stuff doesn't matter while on the boundaries of the layer. What if there was a DBMS that could let you define both simple versions of person and customer, and the DBMS would integrate the various views as real objects?
An AODBMS would be able to define various dimensions of the same entity and provide a way for the simplified dimensional slice to integrate the various views into a single database entity.

Introduction to Aspect Query Language

In this document we will discuss a new query language called "aspect query language" which allows you to write queries against Transcendental Beans, the aspect oriented database. AQL is similar to other query languages in that it starts with a familiar select style syntax. It has results and condition where clauses. The results from an AQL query can be an instance, a reference to the result, a bean instance derived from the query result, a collection of one of these, or an aspect of one of these results. What does that mean? An aspect can be thought of as data that lives in another dimension, but is united by the AODBMS.

A schema is defined in a variety of ways, the motivations of which are to satisfy different roles of users. For example take the definition of a person:

class Person

String name

String phoneNumber

Suppose that you want an application to monitor who changes the values of a person? You might want to add a field modifiedBy to the Person class. This seems fine for the one application, but what about another application that wants to update another database with changes that come from the person database? This application might need to add a field timeModified to the person class:

   class Person     String name     String phoneNumber     String userId     Date timeModified 

Not Person is getting messy. There are three distinct applications that have contributed to the definition of Person. What about the next application trying to "reuse" person? More fields gett added for every usage context. This becomes a maintenance nightmare, coordinating the other consumers to update their usage and all. An RDBMS can provide seperations for some of these concerns, but isn't a Person supposed to describe things about a person? These fields timeModified and modifiedBy are some sort of metadata about Person, but not really "person" fields.

Maybe a better approach would be to seperate these fields from the domain object of Person, an aspect can be defined that introduces needed fields to support the concern of the aspect, so maybe the Person should look like this:

@ChangeTracked

@Audited

class Person

String name

String phoneNumber

This seems a little better, Person is clean, but it is annotated with these other concerns. Even better would be to support this annotation to a class in the AODBMS DML?

annotate Person ChangeTracked, Audited

Now, all the applications can live without even knowing about each other.

What about getting that data back? AQL can be used to retrieve the metadata from the AODBMS by asking for the aspect in teh result specifier:

select aspect(Audit) from Person where name = 'mike'

returns the userId that modified the definition of person last.

Technical White Paper

Application Architecture using a Native Aspect Oriented Database

Level: Intermediate

March 16, 2007

Version 1.0

Abstract: The architecture of an application is chosen to enable the development of the software that achieve the goals of the business at hand. Many times an architecture is chosen from a pattern or template of common architectures such as MVC or SOA. An architecture is created to achieve specific goals usually controlling complexity. Tools are created to achieve the same goal as well. An Aspect Oriented Database is being created and it will have the goal of simplifying use cases involved with data management. Typically, this is related to the model in an MVC architecture, or the domain model in SOA. Building an application with an AODBMS will motivate alternative choices when designing an architecture for your application.

Architecture impacts with framework usage: many web frameworks provide a controller implementation which simplifies your application development effort. There are many persistence frameworks that simplify the effort of storing an object in a relational database.

MVC is orthogonal to your business concerns. The MVC architecture divides the concerns of your application into three categories. Concerns can be modeled fitting this approach, but there is some divergence from the true concept to make it fit into such a structure. There are typically more than three kinds of concepts that an application needs to deal with The MVC breakdown is an effort at mapping your application's classes into these kinds of types.

AOP allows for the implementation of design patterns are first class language structures

An application is created to satisfy business goals. A business lives within a domain of concepts.

MVC was created as an approach to controlling complexity. The partitioning of concerns into this triad is simple and should be understandable by a large community of developers. As applications become more complex, this complexity must be addressed with various techniques.

Models

Reduction

Partitioning

Frameworks

Design Patterns

AOP

AOP has tradionally been associated with modularizign behavior that is scattered accross a system. So what does AOP have to do with data management? There are many things that an application needs to do with it's data. Discovery of the objects, managemnt of it's state, navigation of relationships, and other things. But there are many patterns found in persistent information that require extra fields of columns in a relationsl database in order to implement the concepts. For example a revision history of an object, such as a warehousing application would add effect start and end times to the row and make a new row for each update. This can be expressed as an aspect of the object under revision. The aspect data is orthogonal to the application data, that is it is seperate from, but united by the need of the feature applied to the object. An aspect oriented database would have native support for this feature (concern).

Persistent Data Aspects

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.

Aspect Query Language

An aspect oriented database should support an aspect oriented query language. What would the aspect paradigm do to influence other query languages? There is SQL, JDOQL, EJBQL, OQL, and others. AQL or "Aspect Query Language" would be a query language that supports queries against an aspect oriented database. There are persistent aspects, and persistent data that has been annotated by aspect introduced metadata. An aspect oriented database is a regular database that contains metadata or out of band data integrated with objects. Sure anydatabase can create metadata tables and join it to another table. So what is special about the aspect metadata? In part is a matter of representation, that is there will be keywords distinguishing the aspect data from the object data. The other side of the power of aspect data management is the implicit introduction of information based on contexts of the usage of objects in relationships.

Contextual Relationships

The real world if full of context that introduces meaning into our data. DBMS systems can benefit from the management of these contexts and a representional approach to defining what the meaning related contexts are.

What is a relationship? There are two parties, and a rolle that describes the relationship. So a customer could be related to an address with the roll of billing address. But the same customer could be related to another address with a different role called sales address. There could be even more address-customer relationships with different roles. So what if you just said customer has an address. and that is all you need to know (as a user of "customer")? The role of the relationship is describing it's context.

There are two sides to this situation. There is the user of an information model, and the author of the information model. Both want it simplest for themself. Traditional techniques for defining relationships with many roles or contexts are that the structure contains the names of the role as the field name defining the relationship. There are maybe totally seperate models for a sales domain and for a billing domain, so sometimes the model never even integrates these concepts together.

Why not try to have the best of both worlds? That is for a user, just refer to th4e address as the address, and the author can determine what the various kinds of customer-address relationships can exist. This is a ternary relationship. If this is to be used in SQL, the queries to navigate such a model would become too burdensom to be usable to a wide audience.