Rules-based versioned relationships

[timsknt]

Hi all,

I posted some thoughts on my blog (http://timhigh.wordpress.com/2008/10/31/lessons-from-jboss-envers/) about potential future enhancements to Envers, including:

1) More flexible "specific version relationships" (e.g. version 5 of Foo refers to version 3 of Bar)

2) Rules-based relationships:
- Foo refers to the LATEST version of Bar
- Bar refers to the ACTIVE or WRITABLE version of Baz

and so on. What do you guys think about that? It seems like it wouldn't be too hard to add a "type" to the @Versioned annotation (e.g. SPECIFIC, GENERAL (AKA LATEST), RULE), then a second attribute called "rule" which would define conditions that could be translated into a WHERE clause:

Example: RULE = "Latest"
------------------------------
@Versioned(type=VersionReferenceType.RULE, rule="MAX(Bar.version)")
private Bar bar;

OR

@Versioned(type=VersionReferenceType.LATEST)
private Bar bar;

Example: RULE = “Latest Writable�
----------------------------------------
@Versioned(type=VersionReferenceType.RULE, rule=�LATEST(Bar.status=Bar.STATUS_WRITABLE)�)
private Bar bar;

In order to keep it as usable and simple as possible, it might be best to stay away from SQL query specifics (which can get quirky) in favor of a language that is more amenable to versioning concepts and OO. Perhaps some terms (like LATEST and ACTIVE) could be built-in to Envers, and configured at the class level:

@Entity
@Versioned(activeRule="Foo.status == Foo.STATUS_ACTIVE")
public class Foo {
...
}

[plaky]

Hi,

I think it's a good idea, but there are more functions I would see in envers (2.0?).
I'm thinking about implementing bitemporal versioning in envers (fully configurable, valid from/to properties ...). So this addon is also needed.

The bad thing is: This are really great changes, custom EntityPersisters are needed, Criteria-API must be improved, VersionsReader must be extended, but a greate job. :)

@adam: Thought about a sticky topic to discuss the future of envers? :) Would be really great to discuss this. Have you more detailed plans about envers-2.0 and the generarl architecture? Would you make major changes or is envers-2.0 compatible to envers 1.x ?

kind regards,

sebastian

[adamw]

Hello,

the "LATEST" and "SAME" (meaning: same revision) types will be really easy to implement (especially that "SAME" is the default now ;) ). As for the rule - I understand that the additional parameter would take a query (lets say, an HQL condition - people are used to that - on properties of the referenced class), and when used, return the newest revision, satisfying the given query? That shouldn't be hard to implement too ...

The class-level rule would apply by default to any relations to that class?

Adam

[adamw]

Plaky:
Well, what would you call Envers-2.0? As Envers is now a module of Hibernate, both will share the same release cycle.

I don't have any detailed plans yet - so far the focus is to complete adding support for JPA constructs (two types of inheritance left).

But if you've got any ideas, or even better, if you'd like to conitrbute - please write/do :)

Adam

[plaky]

Hi,

we are evaluating concepts for bitemporal versioning in a very dynamic way. No dependencies e.g. to a calendar date and so on.

I'm not sure if I am allowed to contribute the changes we make (perhaps) to envers. If not I try to implement features on private time. I made some other changes to envers which I will contribute next days.

One change is a configurable DeleteModification. You can specify which fields should be saved null and which shouldn't be set so null in deleted revision. We need this feature cause we have defined one column as primary key in hibernate but three columns in database tables (the hibernate id is unique, but we need more primary keys to cluster ...).

I hope I can spent some days soon to contribute some things and to write down some conecpts.

kind regards

sebastian

[adamw]

Great! Looking forward to your contributions :)

With the deleted columns - so you have something like a "business key", which isn't the primary key? (a unique constraint on some fields other than the primary key).

--
Adam

[plaky]

Our primary keys are not mapped one-to-one from database to or-mapper.

Our database-key is a composite key with fields field1, field2, field3.

Our o/r-primary key is only field1. So if I try to delete an entity I get a ConstraintViolationException (cause field1, field2 and field3 are primary key and not-null).
No I changed envers to configure how a delete entity should be persisted. Every field can be annotated with a DeleteConfiguration annotation with values SET_NULL or KEEP_VALUE. Another way is to configure the ModDeleteUnit to another one which didn't modify the fields, only the revision number and revision type.