RE: [binarycloud-dev] Implementing version control/history

[Alok K. D. <al...@dh...>]

An interesting problem becomes maintaining some mechanism of storing
unique ids which are not the primary key of a given entity table and are
not unique.  After some high level thinking on the subject, we had
decided to store all unique object identifiers, let's call them OID for
short, or, keeping with bc nomenclature, EID, in a separate table from
which any new entity creation process would request and receive a new
EID before inserting a new entity into it's entity table.

The EID table would store the EID and the entity table.  Adding columns
to this table allows very cool things such as locking entities (set a
flag in the central EID table), check-in and check-out of entities, etc.

This versioning business will also have significant impact on the fields
of type "pointer".  I.e. if the referred entity type is versioned, do
you store the EID, or the actual ID from the entity's table (in order to
point to a particular version of the entity as opposed to always
pointing to the latest).  This, perhaps, needs to be configurable as
well.  Using the furbee_type_id field from entity_new.xml, let's say
that furbee_types are versioned - because Furbees, Inc. routinely
changes type definitions, and a given instance of a furbee's type should
never change.  In this case, we want to always point to the same version
of the type.

[ *snip* ]
<field>
            <name>furbee_type_id</name>
            <label>Furbee type ID</label>
            <desc>The id of the type of furbee</desc>
            <path>furbee_type_id</path>
            <required>true</required>
            <type>
                <dbtype>int</dbtype>
                <!--
                note the "pointer" type
                this field is a pointer to another entity, and a
                foreign key in the database.  
                -->
                <type>versioned_pointer</type>
	    <!--
		If we had parameters in the XML definition, we could do
something like:
		<type param="versioned">pointer</type> - to keep from
creating too many
	  	like types which have only minor variations.
	    -->
                <!--
                form above, the entity name to use for requesting
                data from this pointer
                -->
                <entity>furbee_type</entity>
                <maxlength>20</maxlength>
                <format>/[\w\s_\-\.]{0,20}/</format>
            </type>
</field>
[ *snip* ]

Cool stuff.

Al

> -----Original Message-----
> From: bin...@li... 
> [mailto:bin...@li...] On 
> Behalf Of Alex Black
> Sent: Thursday, August 23, 2001 1:33 PM
> To: binarycloud-dev
> Subject: Re: [binarycloud-dev] Implementing version control/history
> 
> 
> > On Sat, Sep 22, 2001 at 11:24:42PM -0400, Alok K. Dhir wrote:
> >> 
> >> version is marked as inactive.  This effectively will allow us to 
> >> build an interface with the ability for automatic version control, 
> >> unlimited undo, and so on.
> >> 
> >> Having read through the pre-release docs on r2, it doesn't 
> look like 
> >> there's anything in the core product which will facilitate 
> this.  On 
> >> the other hand, there also doesn't seem to be anything 
> which should 
> >> hinder this.
> > 
> > We have a few versioned entities.  We basically implement 
> and override 
> > the necessary methods in the derived class.  For example, the
> > VersionedObjectManager::Set() can do whatever you want or 
> you can just 
> > call the
> > parent::Add() and get the system default behaviour.  It's not 
> > automatic, but functional.
> 
> Heh, cool.
> 
> Ah, i.e. you're implementing this on an "individual" 
> entityManager basis.
> 
> I'd prefer to add it as a system level extension to the 
> EntityManager, do you agree?
> 
> 
> >> Seems to me that this functionality may belong in the core 
> product, 
> >> with parameters in the XML entity definition files that 
> would enable 
> >> versioning/history automatically.  Comments?
> > 
> > If it's possible to spec out the behaviour of a generic versioned 
> > object in a way that is useful for the majority of the cases, then 
> > this is very feasible.
> > 
> > jpc
> 
> I think so:
> 
> so where one normally would request an entity record id, 
> like: "give me address id 254" you could change the bahavior 
> of Get etc to say "give me address id 245 timestamp latest" 
> or "give me address id 254 city berkeley"
> 
> I think you'd want to implement it as john suggests: 
> VersionedEntityManager, which would override some base methods.
> 
> hmm...
> 
> _a
> 
> 
> _______________________________________________
> binarycloud-dev mailing list bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>