binarycloud-dev

[binarycloud-dev] Implementing version control/history

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

Hello all - I'm seriously considering adopting r2 as the basis for a
fairly sophisticatede knowledge management system which will manage
several object classes (entities) including documents, events, people,
tasks, etc.  One of the project requirements is full version
control/edit histories on any object data.  I.e. when you make edits to
object data and save it, the changed object is stored as a 'new' object,
with a same unique identifier as the previous version, and the previous
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.

I'm curious to hear comments from the developer community on the
feasibility of implementing this requirement using bc r2.

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?

Thanks.

Al

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

[John P. C. <jp...@jp...>]

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.

> 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

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

[Alex B. <en...@tu...>]

>> 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.
> 
>> 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

can you forward this thread? I don't see it?

-a

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

[Alex B. <en...@tu...>]

> 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

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
> 

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

[Alex B. <en...@tu...>]

> 
> 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.

That's interesting. In which case you _could_ just use a normal entity, and
have the actual data entity separate.

> 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.

Yeah. heh. CVS in oracle!

> 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* ]

yes, though I think I'd want to have that "versioned" flag be part of the
top-level entity definition.

...

_a

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

[Alex B. <en...@tu...>]

> Hello all - I'm seriously considering adopting r2 as the basis for a
> fairly sophisticatede knowledge management system which will manage
> several object classes (entities) including documents, events, people,
> tasks, etc.  One of the project requirements is full version
> control/edit histories on any object data.  I.e. when you make edits to
> object data and save it, the changed object is stored as a 'new' object,
> with a same unique identifier as the previous version, and the previous
> 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.

I see the problem and the 'former' post.

If you store like ids you need to be able to pass some other qualifier that
can pick out a unique record.

So, I think this should be in entitymanager - not 'version control' but
something general like 'the unique id on this entity is composed of more
than 2 fields'

it does introduce the potential for complexity, but I see the need and it
makes sense.


> 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.

Correct. I do suggest that we work together to design it into the system,
however.

> I'm curious to hear comments from the developer community on the
> feasibility of implementing this requirement using bc r2.
> 
> 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?

I agree, let's do it.

_a

I'll also respond to JPC, his opinion being the more relevant on here.


> Thanks.
> 
> Al