After a couple of discussion over ML and JIRA-1815 comments below is the
summary of changes that can
be accommodated in Graph Merger util.
Graph Merger Improvements:-
Initial/Old scope:
Initial scope for graph merger util was to merge 2 DataObjects coming from 2
executions of DAS. These DOs were always having
same Type structures and had ChangeSummary. The secondary DO or all in list
DOs were supposed to be wrapped in DataGraphRoot
DO and associated with DataGraph having change summary (by virtue of DAS).
During merge of secondary DO to primary DO, primary DO ChangeSummary was
turned off, so that the secondary DO was getting merged
without any alterations to changeSummary of primary DO. The result - merged
primary DO was later used by user to do required CUD
and send thru das.applyChanges() to DB.
New scope:
User can pass secondaryDO (or list of DOs) which are not contained in
DataGraphRoot and not associated with DataGraph having
change summary. It is possible to use secondaryDO/s to pass in new DO/s
which need to be CREATED in DB.
The original scope is supported "as is" with existing merge signatures -
merge(primaryDO, secondaryDO), merge(listDOs)
The new scope introduces 2 new signatures in merge(primaryDO, secondaryDO,
preservePrimaryChangeSummary-boolean) and
merge(listDOs, preservePrimaryChangeSummary-boolean).
This new flag when passed in TRUE, exhibits the old behavior and when passed
in FALSE - gives the below behavior.
1) When Type structure for same name are different in primaryDO and
secondaryDO (or list) - RuntimeException -
"Graph structures do not match, can not merge! " + propertyName
2) No field level change summary is supported, as before (i.e. no property
ChangeSummary in Type is considered)
3) Secondary DO may or may not be contained in DataGraph. SecondaryDOs are
always considered for CREATE
4) During merge() call - first DO encountered which is in DG and has CS is
considered as primary. If no DO is
matching this condition, any DO can be considered primary and a fresh CS
will be associated with it.
Regards,
Amita
On 10/10/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
>
> I need input at different places -
> 1) when there are SDOs embedded in DataGraphRoot and DataGraphRoot have
> change summaries , it is same as DAS query result.
>
> 2) when SDOs are formed from model and are not embedded in DataGraphRoot
> and don't have change summaries, GraphMerger
> can embed them in DataGraphRoot and start a fresh change summary ( so
> these will get considered as INSERT in db)
>
> 3) how /whether to consider when SDOs are formed from model and are not
> embedded in DataGraphRoot but have Change Summary
> field? Is it possible to mix the change summary from such SDO and the DAS
> Query result SDO (having change summary in DataGraphRoot)?
> I could not get much from SDO spec. (Am sending a different mail for this
> as it's SDO specific question)
>
> 4) when in the incoming DOs for merger, one is like DAS Query (i.e. inside
> DataGraphRoot having change summaries), consider that as primary
> and all others as secondary. (if none is detected like this - can consider
> any DO as primary - this will again effectively give INSERT operations
> -like batch insert)
>
> 5) when the incoming DOs have the same type name but mismatch in
> properties - throw Exception like incompatible graphs and don't go for
> possibility of restructuring Type.
> i.e. consider a case - merge() is called with a primary DO from DAS query
> - where not all the columns of a table are considered. so the formed Type
> does not have all the Properties.
> the secondary DO comes from a complete xsd model and has some more
> properties in its Type.
> Thus both Types have "same name but a different set of properties". During
> merge, when trying to merge secondary in primary, when a property is
> found which is not present in Type from primary - SDO throws some
> Exception - GraphMerger can wrap it in "Incompatible Graph" exception
> and quit merge.
>
> Regards,
> Amita
>
> On 10/9/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> >
> > Trying to summarize the possible combinations below. Have a question at
> > the end.
> >
> > Cases:
> > Data Objects can be formed in the context of DAS in three ways -
> > 1) static using model - programmatic
> > 2) dynamic using SDO apis - programmatic
> > 3) dynamic using queries - DAS query
> >
> > It should be possible to merge any of these. in pair(primary, secondary)
> > or in list and in nested fashion (parent-child).
> >
> > merge() api in GraphMerger has 2 signatures merge(primary, secondary)
> > and merge(list)
> >
> > so test cases like below should work (similar for merge(List))
> > a> merge(primary - static DO, secondary - static DO)
> > b> merge(primary - dynamic DO, secondary - dynamic DO)
> > c> merge(primary - static DO, secondary - dynamic DO)
> > d> merge(primary - das query result DO, secondary - dynamic DO)
> > e> merge(primary - das query DO, secondary - static DO)
> >
> > primary and secondary can be simple DOs or nested DOs (parent-child)
> >
> > If we can provide this, it will add flexibility to GraphMerger utility
> > and will be helpful for external
> > services which can use it to merge any possibility (1),2),3)) completely
> > disconnected and without any
> > knowledge of DAS Config and use DAS only at then end to flush the merge
> > result to DB. The only requirement
> > from DAS is the final merged Data Graph should possess correct change
> > summary with respect to the data
> > in database. So that the generated commands against the database will
> > succeed.
> >
> > When the commands conflict with existing data, DAS can wrap the
> > SQLException and report to user.
> >
> > Question:
> > I could see one problem which can be solved in 2 different ways, it is -
> >
> > when primary DO comes from DAS Query and if the query does not have all
> > columns
> > from the tables involved (only a subset of columns), the DataObject thus
> > formed
> > does not have all the properties/features. If the secondary DO contains
> > these
> > features, there are 2 possibilities -
> > 1] the feature is missing in primary but can be added to DO structure
> > 2] the feature is a mistake in secondary and should be rejected
> >
> > e.g. table SONG{ID, TITLE, SINGERID}
> > merge(primary - DAS Query, secondary - static DO from SOND.xsd)
> > DAS Squery = SELECT ID, TITLE FROM SONG
> > SONG.xsd - SONG{ID, TITLE, SINGERID}
> >
> > when merge() is attempted, and secondary graph contains SINGERID, (but
> > primary graph lacks it, as DAS
> > uses only columns from queries to form DO structure), what should
> > SINGERID be detected as - a valid
> > property or junk? For the time being to keep it flexible we can take
> > aproach 1] or otherwise
> > modify merge() to pass in a flag like -
> > mergeMissingProperties=true/false.
> >
> > Please let me know your comments.
> >
> > Regards,
> > Amita
> >
> > On 10/7/07, Adriano Crestani <[EMAIL PROTECTED] > wrote:
> > >
> > > Maybe DAS could detect this conflict and throw a specifically
> > > Exception for
> > > this case and reporting it to the user.
> > >
> > > Regards,
> > > Adriano Crestani
> > >
> > > On 10/5/07, Amita Vadhavkar < [EMAIL PROTECTED]> wrote:
> > > >
> > > > GraphMerger utility so far assumed that the merge(do1, do2) will
> > > happen on
> > > > DOs
> > > > which are contained in DataGraphRoot and have changeSummary
> > > associated
> > > > with
> > > > them.
> > > >
> > > > Looking at JIRA-1815, it shows a valid case when an user wants to
> > > merge 2
> > > > DOs (which do not have any knowledge of DataGraphRoot) and may be
> > > without
> > > > change
> > > > summary associated with them (like simply created using
> > > model/generated
> > > > factories)
> > > > i.e. user is supplying static DOs and information about its unique
> > > PK to
> > > > GraphMerger
> > > > but not associating any DAS config to GraphMerger.
> > > >
> > > > DAS GraphMerge can help in merge() of such DOs by internally
> > > detecting if
> > > > these
> > > > are not contained in DataGraphRoot and performing necessary
> > > containment
> > > > and
> > > > start
> > > > of changeSummary. and then user can use DAS to do applyChange() of
> > > the
> > > > merge
> > > > result
> > > > to database.
> > > >
> > > > If such arbitrary dataGraphs are conflicting with existing database
> > > table
> > > > data, the
> > > > operation will fail with necessary SQL Exceptions.
> > > >
> > > > Suggestions?
> > > >
> > > >
> > > > Regards,
> > > > Amita
> > > >
> > >
> >
> >
>
