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