Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc) » [Teneo] Replacing persisted elements of an object heirarchy..

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [Teneo] Replacing persisted elements of an object heirarchy..

Show: Today's Messages :: Show Polls :: Message Navigator

[Teneo] Replacing persisted elements of an object heirarchy.. [message #85592]

Wed, 06 June 2007 10:58

Duncan Alexander

Messages: 90
Registered: July 2009

Member

[Not sure if this should be here or in the EMF list...but here goes]

I am building a system which stores statistical metadata in a registry. I need to be able to replace
sections of this metadata but feel I may not be using EMF and Teneo to their full potential here.

The architecture dictates that the statistical metadata is represented in a model from which an EMF
datagraph has been generated. The datagraph is then persisted in a database using Teneo and Hibernate.

The datagraph has a fairly simple heirarchy of the form

Container
- CodeList
- Code
- Code
- ...
- ConceptScheme
- Concept
- Concept
- ...
- KeyFamily
- Attributes...
- Dimensions...
- Measures....
- Agency

-----------------------------

- Metadata is loaded into the system using XML documents structured as above.

- Every element in the datagraph is of type Identifiable which are keyed on unique URNs.

- The model allows relations between the Identifiable objects which is orthogonal to the basic
heirarchy shown above. I.e. Objects contain references to the URNs of other Identifiables.
E.g. Attributes references codes, KeyFamilies reference agencies, Attributes reference concepts etc
etc. The URN keys are generated based on these relationships.

It is a requirement of the system that the 'main sections' of metadata can be replaced, CodeLIsts,
KeyFamilies etc etc e.g. A CodeList and all its codes could be replaced with a new CodeList with the
same URN but with additional codes to those in the original CodeList.

The incoming replacement section of metadata must include direct replacement for any subelements
(codes, concepts etc) which are already referenced by other elements in the datagraph. In otherwords
it must contain a subelement which has the same URN although it may contain additional info over and
above this.

To do this every object keeps track of its references to other objects and the referees (objects
which refer to it). Then, when an object replacement is needed the original section and any sub
elements are loaded from the database and 'unpicked' from the original datagraph, then the
references are transferred onto the new section and this is persisted to the DB and the original
section deleted.

Phew....sound confusing.....yes, because it is and I cant help feeling that I am doing this the
extra long way.

My question is do I need to go through the process of loading all of the elements from the DB and
then calculating all the references and referees for transferal to be able to replace a section of
the datagraph.?

Would it be easier (better) being done directly in the DB by replacing data directly which would
implicitly update the references rather than in the Object layer which requires that object
references have to be moved.?

I hope someone understand the nature of the problem as Im having trouble even explaining it...

kind regards

Duncan

Report message to a moderator

Re: [Teneo] Replacing persisted elements of an object heirarchy.. [message #85663 is a reply to message #85592]

Wed, 06 June 2007 21:11

Martin Taal

Messages: 5468
Registered: July 2009

Senior Member

Hi Duncan,
Yes you can do direct sql statements to solve this, however also I think that also in the object
world you can handle this.

I assume the urn is also the primary key. If this is the case then you can try to create your new
codelist and copy the data from the old codelist into it and add the new information, then you can
try the following:
// read the oldCodeList from the db and copy to the new codelist
// the session should not contain the parent or referers to the oldCodeList.
session.evict(oldCodeList);
session.update(newCodeList); // or use merge
// and then commit

I have not tested this but afaik this will replace the old code list with the new code list without
you needing to read all referers or parents. The referers do not need to be changed because the fk
is either based on the urn (which is the same) or the fk is set the other way around and then the
above session.update should not overwrite it.

btw, the hbdatastore has a method to get all the referers to a certain object. It analyses the model
to automatically create correct hql statements to retrieve this information.

gr. Martin

Duncan ALexander wrote:
> [Not sure if this should be here or in the EMF list...but here goes]
>
> I am building a system which stores statistical metadata in a registry.
> I need to be able to replace sections of this metadata but feel I may
> not be using EMF and Teneo to their full potential here.
>
> The architecture dictates that the statistical metadata is represented
> in a model from which an EMF datagraph has been generated. The datagraph
> is then persisted in a database using Teneo and Hibernate.
>
> The datagraph has a fairly simple heirarchy of the form
>
> Container
> - CodeList
> - Code
> - Code
> - ...
> - ConceptScheme
> - Concept
> - Concept
> - ...
> - KeyFamily
> - Attributes...
> - Dimensions...
> - Measures....
> - Agency
>
> -----------------------------
>
> - Metadata is loaded into the system using XML documents structured as
> above.
>
> - Every element in the datagraph is of type Identifiable which are keyed
> on unique URNs.
>
> - The model allows relations between the Identifiable objects which is
> orthogonal to the basic heirarchy shown above. I.e. Objects contain
> references to the URNs of other Identifiables.
> E.g. Attributes references codes, KeyFamilies reference agencies,
> Attributes reference concepts etc etc. The URN keys are generated based
> on these relationships.
>
> It is a requirement of the system that the 'main sections' of metadata
> can be replaced, CodeLIsts, KeyFamilies etc etc e.g. A CodeList and all
> its codes could be replaced with a new CodeList with the same URN but
> with additional codes to those in the original CodeList.
>
> The incoming replacement section of metadata must include direct
> replacement for any subelements (codes, concepts etc) which are already
> referenced by other elements in the datagraph. In otherwords it must
> contain a subelement which has the same URN although it may contain
> additional info over and above this.
>
> To do this every object keeps track of its references to other objects
> and the referees (objects which refer to it). Then, when an object
> replacement is needed the original section and any sub elements are
> loaded from the database and 'unpicked' from the original datagraph,
> then the references are transferred onto the new section and this is
> persisted to the DB and the original section deleted.
>
> Phew....sound confusing.....yes, because it is and I cant help feeling
> that I am doing this the extra long way.
>
> My question is do I need to go through the process of loading all of the
> elements from the DB and then calculating all the references and
> referees for transferal to be able to replace a section of the datagraph.?
>
> Would it be easier (better) being done directly in the DB by replacing
> data directly which would implicitly update the references rather than
> in the Object layer which requires that object references have to be
> moved.?
>
> I hope someone understand the nature of the problem as Im having trouble
> even explaining it...
>
> kind regards
>
> Duncan
>

--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org

Report message to a moderator

Re: [Teneo] Replacing persisted elements of an object heirarchy.. [message #85753 is a reply to message #85663]

Thu, 07 June 2007 13:18

Duncan Alexander

Messages: 90
Registered: July 2009

Member

Hi Martin,
thanks for the input...always appreciated.

Yes the URN is the primary key. I ll try the evict method that sounds like it could be exactly what
I was after, I hadnt looked at this before. I would rather solve this in the object layer as it will
allow me further scope for extensibility in the future.

I was trying to use delete but I think that because I was creating a new codelist in the same
session as I loaded the old one AND gave it the same URN that hibernate was getting confused.

Is the HbDataStore.computeRefers the method you were talking about ?

regards

Duncan

Martin Taal wrote:
> Hi Duncan,
> Yes you can do direct sql statements to solve this, however also I think
> that also in the object world you can handle this.
>
> I assume the urn is also the primary key. If this is the case then you
> can try to create your new codelist and copy the data from the old
> codelist into it and add the new information, then you can try the
> following:
> // read the oldCodeList from the db and copy to the new codelist
> // the session should not contain the parent or referers to the
> oldCodeList.
> session.evict(oldCodeList);
> session.update(newCodeList); // or use merge
> // and then commit
>
> I have not tested this but afaik this will replace the old code list
> with the new code list without you needing to read all referers or
> parents. The referers do not need to be changed because the fk is either
> based on the urn (which is the same) or the fk is set the other way
> around and then the above session.update should not overwrite it.
>
> btw, the hbdatastore has a method to get all the referers to a certain
> object. It analyses the model to automatically create correct hql
> statements to retrieve this information.
>
> gr. Martin
>
> Duncan ALexander wrote:
>> [Not sure if this should be here or in the EMF list...but here goes]
>>
>> I am building a system which stores statistical metadata in a
>> registry. I need to be able to replace sections of this metadata but
>> feel I may not be using EMF and Teneo to their full potential here.
>>
>> The architecture dictates that the statistical metadata is represented
>> in a model from which an EMF datagraph has been generated. The
>> datagraph is then persisted in a database using Teneo and Hibernate.
>>
>> The datagraph has a fairly simple heirarchy of the form
>>
>> Container
>> - CodeList
>> - Code
>> - Code
>> - ...
>> - ConceptScheme
>> - Concept
>> - Concept
>> - ...
>> - KeyFamily
>> - Attributes...
>> - Dimensions...
>> - Measures....
>> - Agency
>>
>> -----------------------------
>>
>> - Metadata is loaded into the system using XML documents structured as
>> above.
>>
>> - Every element in the datagraph is of type Identifiable which are
>> keyed on unique URNs.
>>
>> - The model allows relations between the Identifiable objects which is
>> orthogonal to the basic heirarchy shown above. I.e. Objects contain
>> references to the URNs of other Identifiables.
>> E.g. Attributes references codes, KeyFamilies reference agencies,
>> Attributes reference concepts etc etc. The URN keys are generated
>> based on these relationships.
>>
>> It is a requirement of the system that the 'main sections' of metadata
>> can be replaced, CodeLIsts, KeyFamilies etc etc e.g. A CodeList and
>> all its codes could be replaced with a new CodeList with the same URN
>> but with additional codes to those in the original CodeList.
>>
>> The incoming replacement section of metadata must include direct
>> replacement for any subelements (codes, concepts etc) which are
>> already referenced by other elements in the datagraph. In otherwords
>> it must contain a subelement which has the same URN although it may
>> contain additional info over and above this.
>>
>> To do this every object keeps track of its references to other objects
>> and the referees (objects which refer to it). Then, when an object
>> replacement is needed the original section and any sub elements are
>> loaded from the database and 'unpicked' from the original datagraph,
>> then the references are transferred onto the new section and this is
>> persisted to the DB and the original section deleted.
>>
>> Phew....sound confusing.....yes, because it is and I cant help feeling
>> that I am doing this the extra long way.
>>
>> My question is do I need to go through the process of loading all of
>> the elements from the DB and then calculating all the references and
>> referees for transferal to be able to replace a section of the
>> datagraph.?
>>
>> Would it be easier (better) being done directly in the DB by replacing
>> data directly which would implicitly update the references rather than
>> in the Object layer which requires that object references have to be
>> moved.?
>>
>> I hope someone understand the nature of the problem as Im having
>> trouble even explaining it...
>>
>> kind regards
>>
>> Duncan
>>
>
>

Report message to a moderator

Re: [Teneo] Replacing persisted elements of an object heirarchy.. [message #85768 is a reply to message #85753]

Thu, 07 June 2007 13:33

Martin Taal

Messages: 5468
Registered: July 2009

Senior Member

Hi Duncan,
It is the getCrossReferencers method.

gr. Martin

Duncan ALexander wrote:
> Hi Martin,
> thanks for the input...always appreciated.
>
> Yes the URN is the primary key. I ll try the evict method that
> sounds like it could be exactly what I was after, I hadnt looked at this
> before. I would rather solve this in the object layer as it will allow
> me further scope for extensibility in the future.
>
> I was trying to use delete but I think that because I was creating a new
> codelist in the same session as I loaded the old one AND gave it the
> same URN that hibernate was getting confused.
>
> Is the HbDataStore.computeRefers the method you were talking about ?
>
> regards
>
> Duncan
>
> Martin Taal wrote:
>> Hi Duncan,
>> Yes you can do direct sql statements to solve this, however also I
>> think that also in the object world you can handle this.
>>
>> I assume the urn is also the primary key. If this is the case then you
>> can try to create your new codelist and copy the data from the old
>> codelist into it and add the new information, then you can try the
>> following:
>> // read the oldCodeList from the db and copy to the new codelist
>> // the session should not contain the parent or referers to the
>> oldCodeList.
>> session.evict(oldCodeList);
>> session.update(newCodeList); // or use merge
>> // and then commit
>>
>> I have not tested this but afaik this will replace the old code list
>> with the new code list without you needing to read all referers or
>> parents. The referers do not need to be changed because the fk is
>> either based on the urn (which is the same) or the fk is set the other
>> way around and then the above session.update should not overwrite it.
>>
>> btw, the hbdatastore has a method to get all the referers to a certain
>> object. It analyses the model to automatically create correct hql
>> statements to retrieve this information.
>>
>> gr. Martin
>>
>> Duncan ALexander wrote:
>>> [Not sure if this should be here or in the EMF list...but here goes]
>>>
>>> I am building a system which stores statistical metadata in a
>>> registry. I need to be able to replace sections of this metadata but
>>> feel I may not be using EMF and Teneo to their full potential here.
>>>
>>> The architecture dictates that the statistical metadata is
>>> represented in a model from which an EMF datagraph has been
>>> generated. The datagraph is then persisted in a database using Teneo
>>> and Hibernate.
>>>
>>> The datagraph has a fairly simple heirarchy of the form
>>>
>>> Container
>>> - CodeList
>>> - Code
>>> - Code
>>> - ...
>>> - ConceptScheme
>>> - Concept
>>> - Concept
>>> - ...
>>> - KeyFamily
>>> - Attributes...
>>> - Dimensions...
>>> - Measures....
>>> - Agency
>>>
>>> -----------------------------
>>>
>>> - Metadata is loaded into the system using XML documents structured
>>> as above.
>>>
>>> - Every element in the datagraph is of type Identifiable which are
>>> keyed on unique URNs.
>>>
>>> - The model allows relations between the Identifiable objects which
>>> is orthogonal to the basic heirarchy shown above. I.e. Objects
>>> contain references to the URNs of other Identifiables.
>>> E.g. Attributes references codes, KeyFamilies reference agencies,
>>> Attributes reference concepts etc etc. The URN keys are generated
>>> based on these relationships.
>>>
>>> It is a requirement of the system that the 'main sections' of
>>> metadata can be replaced, CodeLIsts, KeyFamilies etc etc e.g. A
>>> CodeList and all its codes could be replaced with a new CodeList with
>>> the same URN but with additional codes to those in the original
>>> CodeList.
>>>
>>> The incoming replacement section of metadata must include direct
>>> replacement for any subelements (codes, concepts etc) which are
>>> already referenced by other elements in the datagraph. In otherwords
>>> it must contain a subelement which has the same URN although it may
>>> contain additional info over and above this.
>>>
>>> To do this every object keeps track of its references to other
>>> objects and the referees (objects which refer to it). Then, when an
>>> object replacement is needed the original section and any sub
>>> elements are loaded from the database and 'unpicked' from the
>>> original datagraph, then the references are transferred onto the new
>>> section and this is persisted to the DB and the original section
>>> deleted.
>>>
>>> Phew....sound confusing.....yes, because it is and I cant help
>>> feeling that I am doing this the extra long way.
>>>
>>> My question is do I need to go through the process of loading all of
>>> the elements from the DB and then calculating all the references and
>>> referees for transferal to be able to replace a section of the
>>> datagraph.?
>>>
>>> Would it be easier (better) being done directly in the DB by
>>> replacing data directly which would implicitly update the references
>>> rather than in the Object layer which requires that object references
>>> have to be moved.?
>>>
>>> I hope someone understand the nature of the problem as Im having
>>> trouble even explaining it...
>>>
>>> kind regards
>>>
>>> Duncan
>>>
>>
>>

--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org

Report message to a moderator

Re: [Teneo] Replacing persisted elements of an object heirarchy.. [message #86170 is a reply to message #85768]

Wed, 13 June 2007 09:36

Duncan Alexander

Messages: 90
Registered: July 2009

Member

Hi Martin,
I have a follow up question in relation to your suggestion to use evict and update. Would the
cascade settings in my hibernate.xml file need to be changed from that which is generated by Teneo
by default for this behaviour to work ?

Currently cascade is set to all for any entity relations .

Duncan

Martin Taal wrote:
> Hi Duncan,
> It is the getCrossReferencers method.
>
> gr. Martin
>
> Duncan ALexander wrote:
>> Hi Martin,
>> thanks for the input...always appreciated.
>>
>> Yes the URN is the primary key. I ll try the evict method that
>> sounds like it could be exactly what I was after, I hadnt looked at
>> this before. I would rather solve this in the object layer as it will
>> allow me further scope for extensibility in the future.
>>
>> I was trying to use delete but I think that because I was creating a
>> new codelist in the same session as I loaded the old one AND gave it
>> the same URN that hibernate was getting confused.
>>
>> Is the HbDataStore.computeRefers the method you were talking about ?
>>
>> regards
>>
>> Duncan
>>
>> Martin Taal wrote:
>>> Hi Duncan,
>>> Yes you can do direct sql statements to solve this, however also I
>>> think that also in the object world you can handle this.
>>>
>>> I assume the urn is also the primary key. If this is the case then
>>> you can try to create your new codelist and copy the data from the
>>> old codelist into it and add the new information, then you can try
>>> the following:
>>> // read the oldCodeList from the db and copy to the new codelist
>>> // the session should not contain the parent or referers to the
>>> oldCodeList.
>>> session.evict(oldCodeList);
>>> session.update(newCodeList); // or use merge
>>> // and then commit
>>>
>>> I have not tested this but afaik this will replace the old code list
>>> with the new code list without you needing to read all referers or
>>> parents. The referers do not need to be changed because the fk is
>>> either based on the urn (which is the same) or the fk is set the
>>> other way around and then the above session.update should not
>>> overwrite it.
>>>
>>> btw, the hbdatastore has a method to get all the referers to a
>>> certain object. It analyses the model to automatically create correct
>>> hql statements to retrieve this information.
>>>
>>> gr. Martin
>>>
>>> Duncan ALexander wrote:
>>>> [Not sure if this should be here or in the EMF list...but here goes]
>>>>
>>>> I am building a system which stores statistical metadata in a
>>>> registry. I need to be able to replace sections of this metadata
>>>> but feel I may not be using EMF and Teneo to their full potential here.
>>>>
>>>> The architecture dictates that the statistical metadata is
>>>> represented in a model from which an EMF datagraph has been
>>>> generated. The datagraph is then persisted in a database using Teneo
>>>> and Hibernate.
>>>>
>>>> The datagraph has a fairly simple heirarchy of the form
>>>>
>>>> Container
>>>> - CodeList
>>>> - Code
>>>> - Code
>>>> - ...
>>>> - ConceptScheme
>>>> - Concept
>>>> - Concept
>>>> - ...
>>>> - KeyFamily
>>>> - Attributes...
>>>> - Dimensions...
>>>> - Measures....
>>>> - Agency
>>>>
>>>> -----------------------------
>>>>
>>>> - Metadata is loaded into the system using XML documents structured
>>>> as above.
>>>>
>>>> - Every element in the datagraph is of type Identifiable which are
>>>> keyed on unique URNs.
>>>>
>>>> - The model allows relations between the Identifiable objects which
>>>> is orthogonal to the basic heirarchy shown above. I.e. Objects
>>>> contain references to the URNs of other Identifiables.
>>>> E.g. Attributes references codes, KeyFamilies reference agencies,
>>>> Attributes reference concepts etc etc. The URN keys are generated
>>>> based on these relationships.
>>>>
>>>> It is a requirement of the system that the 'main sections' of
>>>> metadata can be replaced, CodeLIsts, KeyFamilies etc etc e.g. A
>>>> CodeList and all its codes could be replaced with a new CodeList
>>>> with the same URN but with additional codes to those in the original
>>>> CodeList.
>>>>
>>>> The incoming replacement section of metadata must include direct
>>>> replacement for any subelements (codes, concepts etc) which are
>>>> already referenced by other elements in the datagraph. In otherwords
>>>> it must contain a subelement which has the same URN although it may
>>>> contain additional info over and above this.
>>>>
>>>> To do this every object keeps track of its references to other
>>>> objects and the referees (objects which refer to it). Then, when an
>>>> object replacement is needed the original section and any sub
>>>> elements are loaded from the database and 'unpicked' from the
>>>> original datagraph, then the references are transferred onto the new
>>>> section and this is persisted to the DB and the original section
>>>> deleted.
>>>>
>>>> Phew....sound confusing.....yes, because it is and I cant help
>>>> feeling that I am doing this the extra long way.
>>>>
>>>> My question is do I need to go through the process of loading all of
>>>> the elements from the DB and then calculating all the references and
>>>> referees for transferal to be able to replace a section of the
>>>> datagraph.?
>>>>
>>>> Would it be easier (better) being done directly in the DB by
>>>> replacing data directly which would implicitly update the references
>>>> rather than in the Object layer which requires that object
>>>> references have to be moved.?
>>>>
>>>> I hope someone understand the nature of the problem as Im having
>>>> trouble even explaining it...
>>>>
>>>> kind regards
>>>>
>>>> Duncan
>>>>
>>>
>>>
>
>

Report message to a moderator

Re: [Teneo] Replacing persisted elements of an object heirarchy.. [message #86184 is a reply to message #86170]

Wed, 13 June 2007 11:23

Martin Taal

Messages: 5468
Registered: July 2009

Senior Member

Hi Duncan,
I am not sure, you need to test it out, if the cascade is all then also the children of an evicted
object will be evicted. On the other hand these children are again added to the session again
through the update.

gr, Martin

Duncan ALexander wrote:
>
> Hi Martin,
> I have a follow up question in relation to your suggestion to use
> evict and update. Would the cascade settings in my hibernate.xml file
> need to be changed from that which is generated by Teneo by default for
> this behaviour to work ?
>
> Currently cascade is set to all for any entity relations .
>
> Duncan
>
> Martin Taal wrote:
>> Hi Duncan,
>> It is the getCrossReferencers method.
>>
>> gr. Martin
>>
>> Duncan ALexander wrote:
>>> Hi Martin,
>>> thanks for the input...always appreciated.
>>>
>>> Yes the URN is the primary key. I ll try the evict method that
>>> sounds like it could be exactly what I was after, I hadnt looked at
>>> this before. I would rather solve this in the object layer as it will
>>> allow me further scope for extensibility in the future.
>>>
>>> I was trying to use delete but I think that because I was creating a
>>> new codelist in the same session as I loaded the old one AND gave it
>>> the same URN that hibernate was getting confused.
>>>
>>> Is the HbDataStore.computeRefers the method you were talking about ?
>>>
>>> regards
>>>
>>> Duncan
>>>
>>> Martin Taal wrote:
>>>> Hi Duncan,
>>>> Yes you can do direct sql statements to solve this, however also I
>>>> think that also in the object world you can handle this.
>>>>
>>>> I assume the urn is also the primary key. If this is the case then
>>>> you can try to create your new codelist and copy the data from the
>>>> old codelist into it and add the new information, then you can try
>>>> the following:
>>>> // read the oldCodeList from the db and copy to the new codelist
>>>> // the session should not contain the parent or referers to the
>>>> oldCodeList.
>>>> session.evict(oldCodeList);
>>>> session.update(newCodeList); // or use merge
>>>> // and then commit
>>>>
>>>> I have not tested this but afaik this will replace the old code list
>>>> with the new code list without you needing to read all referers or
>>>> parents. The referers do not need to be changed because the fk is
>>>> either based on the urn (which is the same) or the fk is set the
>>>> other way around and then the above session.update should not
>>>> overwrite it.
>>>>
>>>> btw, the hbdatastore has a method to get all the referers to a
>>>> certain object. It analyses the model to automatically create
>>>> correct hql statements to retrieve this information.
>>>>
>>>> gr. Martin
>>>>
>>>> Duncan ALexander wrote:
>>>>> [Not sure if this should be here or in the EMF list...but here goes]
>>>>>
>>>>> I am building a system which stores statistical metadata in a
>>>>> registry. I need to be able to replace sections of this metadata
>>>>> but feel I may not be using EMF and Teneo to their full potential
>>>>> here.
>>>>>
>>>>> The architecture dictates that the statistical metadata is
>>>>> represented in a model from which an EMF datagraph has been
>>>>> generated. The datagraph is then persisted in a database using
>>>>> Teneo and Hibernate.
>>>>>
>>>>> The datagraph has a fairly simple heirarchy of the form
>>>>>
>>>>> Container
>>>>> - CodeList
>>>>> - Code
>>>>> - Code
>>>>> - ...
>>>>> - ConceptScheme
>>>>> - Concept
>>>>> - Concept
>>>>> - ...
>>>>> - KeyFamily
>>>>> - Attributes...
>>>>> - Dimensions...
>>>>> - Measures....
>>>>> - Agency
>>>>>
>>>>> -----------------------------
>>>>>
>>>>> - Metadata is loaded into the system using XML documents structured
>>>>> as above.
>>>>>
>>>>> - Every element in the datagraph is of type Identifiable which are
>>>>> keyed on unique URNs.
>>>>>
>>>>> - The model allows relations between the Identifiable objects which
>>>>> is orthogonal to the basic heirarchy shown above. I.e. Objects
>>>>> contain references to the URNs of other Identifiables.
>>>>> E.g. Attributes references codes, KeyFamilies reference agencies,
>>>>> Attributes reference concepts etc etc. The URN keys are generated
>>>>> based on these relationships.
>>>>>
>>>>> It is a requirement of the system that the 'main sections' of
>>>>> metadata can be replaced, CodeLIsts, KeyFamilies etc etc e.g. A
>>>>> CodeList and all its codes could be replaced with a new CodeList
>>>>> with the same URN but with additional codes to those in the
>>>>> original CodeList.
>>>>>
>>>>> The incoming replacement section of metadata must include direct
>>>>> replacement for any subelements (codes, concepts etc) which are
>>>>> already referenced by other elements in the datagraph. In
>>>>> otherwords it must contain a subelement which has the same URN
>>>>> although it may contain additional info over and above this.
>>>>>
>>>>> To do this every object keeps track of its references to other
>>>>> objects and the referees (objects which refer to it). Then, when an
>>>>> object replacement is needed the original section and any sub
>>>>> elements are loaded from the database and 'unpicked' from the
>>>>> original datagraph, then the references are transferred onto the
>>>>> new section and this is persisted to the DB and the original
>>>>> section deleted.
>>>>>
>>>>> Phew....sound confusing.....yes, because it is and I cant help
>>>>> feeling that I am doing this the extra long way.
>>>>>
>>>>> My question is do I need to go through the process of loading all
>>>>> of the elements from the DB and then calculating all the references
>>>>> and referees for transferal to be able to replace a section of the
>>>>> datagraph.?
>>>>>
>>>>> Would it be easier (better) being done directly in the DB by
>>>>> replacing data directly which would implicitly update the
>>>>> references rather than in the Object layer which requires that
>>>>> object references have to be moved.?
>>>>>
>>>>> I hope someone understand the nature of the problem as Im having
>>>>> trouble even explaining it...
>>>>>
>>>>> kind regards
>>>>>
>>>>> Duncan
>>>>>
>>>>
>>>>
>>
>>

--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org

Report message to a moderator