At the time I started the project, Envers was in Alpha so I wrote what
I needed by hand for my specific needs as well as put into place a
pluggable framework for my ORM implementation. I was not sure that I
was even going to be able to use NHibernate due to my work being a
Microsoft only style of shop, so being able to swap out NHibernate was
paramount to my design. I wasn't going to invest too deeply into
NHibernate-Fu and the various contrib projects until I knew that what
I was making would even be accepted.

My issue at the moment isn't versioning, but hierarchal relationships.
I've already got the versioning solution in place.

Thanks,
Robert

On Fri, Sep 9, 2011 at 9:48 AM,  <[email protected]> wrote:
> Why roll your own when there's NHibernate.Envers
> (https://bitbucket.org/RogerKratz/nhibernate.envers)
>
> On , Robert Elsner <[email protected]> wrote:
>> I've got a model that has been working for versioned objects.
>>
>>
>>
>> //workspace - users container of versioned items
>>
>> public class Workspace : IEntity
>>
>> {
>>
>>    public virtual Id { get; protected set; }
>>
>>    public virtual string WorkspaceName { get; set; }
>>
>>    public virtual ICollection VersionableObjects {
>>
>> get; protected set; }
>>
>>    public virtual User User { get; set; }
>>
>>
>>
>>    public Workspace()
>>
>>    {
>>
>>        this.Id = GuidCombGenerator.Generate();
>>
>>        this.VersionableObjects = new HashSet()
>>
>>    }
>>
>> }
>>
>>
>>
>> //base class for all versioned items, allows quick UI display of all
>>
>> versioned objects, etc.
>>
>> public abstract class VersionedEntity : IEntity
>>
>> {
>>
>>    public virtual Guid Id { get; protected set; }
>>
>>    public virtual Guid EntityKey { get; protected set; }
>>
>>    public virtual byte[] ConcurrencyVersion { get; protected set; }
>>
>>
>>
>>    public virtual int Version { get; set; }
>>
>>    public virtual string Name { get; set; }
>>
>>    public virtual string Description { get; set }
>>
>>
>>
>>    protected VersionedEntity()
>>
>>    {
>>
>>        this.Id = GuidCombGenerator.Generate();
>>
>>        this.EntityKey = GuidCombGenerator.Generate();
>>
>>    }
>>
>>
>>
>> //etc...
>>
>> }
>>
>>
>>
>> public class RuleContainer: VersionedEntity
>>
>> {
>>
>>    public IList RuleList { get; protected set; }
>>
>> }
>>
>>
>>
>> public class Rule : VersionedEntity
>>
>> {
>>
>>
>>
>> }
>>
>>
>>
>> I'm using Table-per-subclass so that for every derived class I've got
>>
>> an additional table.
>>
>>
>>
>> Id is the surrogate key and primary key and is generated client side
>>
>> EntityKey is the object id, or the same id that this entity will have
>>
>> for it's lifetime
>>
>> ConcurrencyVersion is used for NHiberate to detect entity changes
>>
>>
>>
>> A new version is a cloned entity with the version value incremented,
>>
>> I'm leaving out the fields for status tracking, etc.
>>
>>
>>
>> Now here is problem I'm trying to find the best solution.
>>
>>
>>
>> I need to have non-versioned hierarchies.
>>
>>
>>
>> E.g. a relationship map between objects that follows the entity key
>>
>> and not the id key, e.g. a weak key reference.
>>
>>
>>
>> For a Workspace, I map via one-to-many to VersionedEntitiy so that I'm
>>
>> going to call a strong key reference through a table called
>>
>> VersionedEntitiesToParentWorkspace
>>
>>
>>
>> The workspace contains strong key references, but now I need to be
>>
>> able to track a weak hierarchy/relationship between entities.
>>
>>
>>
>> Example:
>>
>>
>>
>> Container A, v1 => Rule A, v1
>>
>> Container A, v1 => Rule B, v1
>>
>> Container A, v1 => Rule C, v1
>>
>> Rule A, v1 => Rule D, v1
>>
>> Rule B, v1 => Rule A, v1
>>
>> Rule C, v1 => NULL
>>
>>
>>
>> Now this relationship needs to be based upon the weak keys, not the strong
>> key.
>>
>>
>>
>> Hence, only the workspace is used to get the actual version.
>>
>>
>>
>> There could exist Rule B, version 2, but only in a specific workspace,
>>
>> I need to reference version 1. But have a data model that allows me to
>>
>> show all versions of Rule b, version 1 through (n)
>>
>>
>>
>> Now it's possible that a later version change, Rule B, version 3 now
>>
>> calls a different set, e.g. a different relationship/hierarchy.
>>
>>
>>
>> All of this implies that I'm needing a versioned parent/child
>>
>> relationship per node/entity
>>
>>
>>
>> VersionedEntity => VersionedHierarchy => VersionedEntity(s)
>>
>>
>>
>> Or maybe there is a better solution?
>>
>>
>>
>> One other solution I'm thinking of is the traditional Node/Tree
>>
>> implementation where it's another table: Nodes
>>
>>
>>
>> I use Id as a surrogate key, and then use another column as the Entity
>>
>> Key and have all the Ancestors/Decendants mapped in another table, and
>>
>> just join to my VersionedEntityTable to get all nodes in that
>>
>> relationship and have the users be able to choose what version they
>>
>> want, and save that structure to their workspace.
>>
>>
>>
>> In an earlier iteration I used composite keys, and the complexity was
>>
>> very high, switching to a surrogate key, made NHibernate behave
>>
>> nicely.
>>
>>
>>
>> The relationships I also had were based upon strong key relationships
>>
>> on the children objects, but user requirements are that they be weak
>>
>> key referenced, and the workspace gives the unique versioned item. I'm
>>
>> trying to avoid a composite key of WorkspaceId, VersionedParentId,
>>
>> VersionedChildId or something like that.
>>
>>
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "nhusers" group.
>>
>> To post to this group, send email to [email protected].
>>
>> To unsubscribe from this group, send email to
>> [email protected].
>>
>> For more options, visit this group at
>> http://groups.google.com/group/nhusers?hl=en.
>>
>>
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "nhusers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/nhusers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.

Reply via email to