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