[jira] Updated: (TUSCANY-1815) das.applyChanges will always do insert instead of update if createDataObject was used

["Amita Vadhavkar (JIRA)" <tu...@ws.apache.org>]

     [ https://issues.apache.org/jira/browse/TUSCANY-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Amita Vadhavkar updated TUSCANY-1815:
-------------------------------------

    Attachment: 1815.patch

Final design changes:-
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.
  

> das.applyChanges will always do insert instead of update if createDataObject was used
> -------------------------------------------------------------------------------------
>
>                 Key: TUSCANY-1815
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1815
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java DAS RDB
>    Affects Versions: Java-DAS-beta1, Java-DAS-Next
>         Environment: DB2 Iseries
>            Reporter: Nick Duncan
>            Assignee: Amita Vadhavkar
>             Fix For: Java-DAS-Next
>
>         Attachments: 1815.patch
>
>
> If I do something like: 
> -------------------------------
>     		DataObject root = das.getCommand("AllAutos").executeQuery();
>     		
>     		DataObject dao = root.createDataObject("t_test");
>     		dao.set("NAME", "NICK");
>     		dao.set("ID", 100);
>     		
>     		das.applyChanges(root);
> -------------------------------------
> There is already a row in the table with primary key 100.  ID is defined in the config xml as being the primary key,  it ignores that ID was set and does an insert statement.  ID is also defined as an auto generated column.
> Basically I was expecting something like Hibernate's savorOrUpdate...   Maybe if the field that represents primary key  is shown to have been changed in the changeSummary, then  DAS will figure out what statement to generate.  
> Where I'm seeing this being a problem is if we get a dataobject that represents a row in the database, and then send it off to a service, we get back another object that has been updated, but since it is a different object then the DAS will think it should do an update?  Merge doesn't  seem to  alleviate this problem either.  Please let me know if I am way off base here.  Thanks

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org