You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Nick Duncan (JIRA)" <tu...@ws.apache.org> on 2007/09/27 23:10:50 UTC
[jira] Created: (TUSCANY-1815) das.applyChanges will always do
insert instead of update if createDataObject was used
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
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
[jira] Resolved: (TUSCANY-1815) das.applyChanges will always do
insert instead of update if createDataObject was used
Posted by "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 resolved TUSCANY-1815.
--------------------------------------
Resolution: Fixed
Changes applied under revision 588159
> 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
[jira] Commented: (TUSCANY-1815) das.applyChanges will always do
insert instead of update if createDataObject was used
Posted by "Amita Vadhavkar (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532606 ]
Amita Vadhavkar commented on TUSCANY-1815:
------------------------------------------
Got your point , work in progress.
Regards,
> 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
>
>
> 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
[jira] Commented: (TUSCANY-1815) das.applyChanges will always do
insert instead of update if createDataObject was used
Posted by "Amita Vadhavkar (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530917 ]
Amita Vadhavkar commented on TUSCANY-1815:
------------------------------------------
In JUnit tests -
GeneratedId.testInsert4 - shows that when generated is true, setInt("ID", 999) is ignored.
Thus, DAS ignores setInt() when generated=true. To turn this off, you can remove this from the
config. Also make sure that the table is created with no "GENERATED ALWAYS AS IDENTITY" clause.
and then do createDataObject().
There is no direct "saveOrUpdate" supported. Also, when generated=true, there is no control on ID.
(i.e. the next ID generated will be decided/generated by DBMS).
For "saveOrUpdate" case, (switch off generated feature), you will need to do a select for ID=100
and see if there is DO. If it is there, use it to modify values and if it is not there do createDataObject()
(with specifying the setInt(ID, 100))
see http://incubator.apache.org/tuscany/das-java-faq.html#DASJava-FAQ-RDBDASsupportforgeneratedkeys
http://incubator.apache.org/tuscany/workingwithgenerateddatabasekeys.html
http://incubator.apache.org/tuscany/configurable-database-generated-keys-support.html
for details of generated keys support.
> 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
>
> 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
[jira] Commented: (TUSCANY-1815) das.applyChanges will always do
insert instead of update if createDataObject was used
Posted by "Luciano Resende (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530866 ]
Luciano Resende commented on TUSCANY-1815:
------------------------------------------
Would you please add your das config as well ?
> 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
>
> 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
[jira] Updated: (TUSCANY-1815) das.applyChanges will always do
insert instead of update if createDataObject was used
Posted by "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
[jira] Commented: (TUSCANY-1815) das.applyChanges will always do
insert instead of update if createDataObject was used
Posted by "Nick Duncan (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531040 ]
Nick Duncan commented on TUSCANY-1815:
--------------------------------------
Thank you for the thorough responses. I wasn't trying to setID so much as just use the ID setter to show which data object I wanted to update.
If GraphMerger would play nicer with dataObjects created from a factory and then merged with a root created from a DAS, then I don't think there would be an issue.
Consider this scenario:
DataObject root = das.getCommand("AllAutos").executeQuery();
AutoTypeImpl at= (AutoTypeImpl) GeneratedFactoryImpl.INSTANCE.createAutoType();
at.setName("nick");
at.setId(100);
DataObject root1 = at.getRootObject();
GraphMerger gm = new GraphMerger();
gm.addPrimaryKey("AutoType.id");
root = gm.merge(root, root1);
das.applyChanges(root);
--Except that will blow up with
java.lang.ClassCastException: java.lang.Integer incompatible with java.util.List
at org.apache.tuscany.sdo.impl.DataObjectImpl.getList(DataObjectImpl.java:375)
I do realize that it works if both root and root1 were derived from a DAS, but that seems to be a limitation
-----------
What I want to do is have a root object that holds onto data objects, originally retrieved from a command. I then want the abiliity to get data objects from any source ( a service, a factory, etc...) and then merge them, and then DAS will either do updates saves or deletes accordingly. As long as the the data objects are of the same type I would think that should work.
If I have data objects of the correct type but were not derived from a das, then I don't see any *clean* way of doing what I want. Thanks.
> 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
>
> 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
[jira] Commented: (TUSCANY-1815) das.applyChanges will always do
insert instead of update if createDataObject was used
Posted by "Amita Vadhavkar (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531763 ]
Amita Vadhavkar commented on TUSCANY-1815:
------------------------------------------
I tried the below test case which is very similar to what you are trying:-
-----------------------------------------------------------------------------------------------------------------------------------
public void testMergeUpdateSingleTable() throws Exception {
//existing records
DAS das = DAS.FACTORY.createDAS(getConfig("CustomersOrdersConfig.xml"), getConnection());
DataObject root = das.getCommand("all customers").executeQuery();
DataObject firstCustomer = root.getDataObject("CUSTOMER[ID=1]");
firstCustomer.delete();//DAS will not automatic createOrReplace , so do delete here and later doing a create
System.out.println("after delete "+XMLHelper.INSTANCE.save(root, "root", "root"));
//create new customer using static SDO - say a service is doing it
String typeUri = "http:///org.apache.tuscany.das.rdb.test/customernew.xsd";
HelperContext context = HelperProvider.getDefaultContext();
CustomernewFactory.INSTANCE.register(context);
ConfigHelper helper = new ConfigHelper();
helper.setDataObjectModel(typeUri);
helper.addTable("CUSTOMER", "CUSTOMER");
helper.addPrimaryKey("CUSTOMER.ID");
GraphMerger gm = new GraphMerger();
DataObject graph = gm.emptyGraph(helper.getConfig());
CUSTOMER c = (CUSTOMER) graph.createDataObject("CUSTOMER");
c.setID(1);
c.setLASTNAME("WilliamsNew");
c.setADDRESS("400 Fourth Street");
System.out.println("c "+XMLHelper.INSTANCE.save(((DataObject)c).getRootObject(), "c", "c"));
gm.addPrimaryKey("CUSTOMER.ID");
DataObject root1 = gm.merge(root, ((DataObject)c).getRootObject());
System.out.println("after merge "+XMLHelper.INSTANCE.save(root1, "root1", "root1"));
das.applyChanges(root1);
}
---------------------------------------------------------------------------------------------------------------------------------
So I am mixing the types from Dynamic DO and Types coming in from model.xsd.
I did not get any ClassCastException but a nice :) SQLIntegrity one like below :-
java.lang.RuntimeException: java.sql.SQLIntegrityConstraintViolationException: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'SQL071002050115810' defined on 'CUSTOMER'.
at org.apache.tuscany.das.rdb.impl.WriteCommandImpl.basicExecute(WriteCommandImpl.java:94)
at org.apache.tuscany.das.rdb.impl.ChangeOperation.execute(ChangeOperation.java:72)
at org.apache.tuscany.das.rdb.impl.Changes.execute(Changes.java:57)
at org.apache.tuscany.das.rdb.impl.ApplyChangesCommandImpl.execute(ApplyChangesCommandImpl.java:68)
at org.apache.tuscany.das.rdb.impl.DASImpl.applyChanges(DASImpl.java:310)
at org.apache.tuscany.das.rdb.test.GraphMergeTests.testMergeUpdateSingleTable(GraphMergeTests.java:217)
....
Caused by: java.sql.SQLIntegrityConstraintViolationException: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'SQL071002050115810' defined on 'CUSTOMER'.
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source)
at org.apache.tuscany.das.rdb.impl.Statement.executeUpdate(Statement.java:172)
at org.apache.tuscany.das.rdb.impl.Statement.executeUpdate(Statement.java:132)
at org.apache.tuscany.das.rdb.impl.Statement.executeUpdate(Statement.java:136)
at org.apache.tuscany.das.rdb.impl.WriteCommandImpl.basicExecute(WriteCommandImpl.java:92)
... 21 more
Caused by: java.sql.SQLException: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'SQL071002050115810' defined on 'CUSTOMER'.
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source)
... 34 more
---------------------------------------------------------------------------------------------------------------------------------
Also I can see a very small fix can solve this exception. In Changed.java execute() method - which is execed for das.applyChanges(root1),
the changes are attempted in order - 1) insert, 2) update, 3) delete
Due to this, even though the test case was trying to do a delete(for ID=1) and then create(for ID=1), the DAS runtime was attempting
INSERT before DELETE and was throwing SQLIntegrity exception.
A simple/quick solution will be follow the order - 1)delete, 2) insert, 3) update - verified that with this, the delete and insert happens one after other
and no exception.
But a better solution will be to maintain the oder of changes user is imposing through the calls. i.e. if user has a mix of many tables in a root
and is doing some complex combination of CUD operations following some logic, DAS needs to preserve this order instead of bucketing all
insert in bucket1, all deletes in bucket2...and then executing the buckets. For this to work, commonj.sdo.ChangeSummary.getChangedDataObjects()
need return "ordered list". Need to confirm this with SDO.
I am putting this in a separate mail on ML to get some feedback from others (DAS+SDO) about what will be the correct approach.
Please see that in the example code you are showing, just creating Type, may not register that Type in DAS context. But
gm.emptyGraph(helper.getConfig()); will enable DAS to create DataObject for that Type.
> 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
>
>
> 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
[jira] Commented: (TUSCANY-1815) das.applyChanges will always do
insert instead of update if createDataObject was used
Posted by "Luciano Resende (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530890 ]
Luciano Resende commented on TUSCANY-1815:
------------------------------------------
Could you try removing : generated="true" from the table element, if I remember correct, when generated keys are being used we will ignore them when sending the data to rdb.
> 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
>
> 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
[jira] Commented: (TUSCANY-1815) das.applyChanges will always do
insert instead of update if createDataObject was used
Posted by "Nick Duncan (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530886 ]
Nick Duncan commented on TUSCANY-1815:
--------------------------------------
<Config xsi:noNamespaceSchemaLocation="http:///org.apache.tuscany.das.rdb/config.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>
<ConnectionInfo>
<ConnectionProperties
driverClass="com.ibm.as400.access.AS400JDBCDriver"
databaseURL="jdbc:as400://adsfadsf"
loginTimeout="600000"
userName="asdfadf"
password="asdfadf"/>
</ConnectionInfo>
<Command name="AllAutos" SQL="select * from duncann.t_test" kind="Select">
<ResultDescriptor columnName="ID" tableName="t_test" columnType="commonj.sdo.Int"/>
<ResultDescriptor columnName="NAME" tableName="t_test" columnType="commonj.sdo.String"/>
</Command>
<Table tableName="t_test" schemaName="duncann">
<Column columnName="ID" primaryKey="true" generated="true" />
<Column columnName="NAME" />
</Table>
</Config>
> 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
>
> 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
[jira] Commented: (TUSCANY-1815) das.applyChanges will always do
insert instead of update if createDataObject was used
Posted by "Amita Vadhavkar (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533302 ]
Amita Vadhavkar commented on TUSCANY-1815:
------------------------------------------
please follow http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg24583.html and give your comments.
> 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
>
>
> 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
[jira] Assigned: (TUSCANY-1815) das.applyChanges will always do
insert instead of update if createDataObject was used
Posted by "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 reassigned TUSCANY-1815:
----------------------------------------
Assignee: Amita Vadhavkar
> 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
>
> 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
[jira] Commented: (TUSCANY-1815) das.applyChanges will always do
insert instead of update if createDataObject was used
Posted by "Nick Duncan (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531817 ]
Nick Duncan commented on TUSCANY-1815:
--------------------------------------
When you say:
------------------
//create new customer using static SDO - say a service is doing it
...
DataObject graph = gm.emptyGraph(helper.getConfig());
CUSTOMER c = (CUSTOMER) graph.createDataObject("CUSTOMER");
-----------------
I don't see how that a Customer from a service could be created in such a way. We would not want a config to be available in every tier of the architecture. We would want our service implementations to accept or send a static data object (or dynamic) and not have to worry about the underlying complexity of tying it to a Config. Basically we want to have a totally detached service oriented architecture.
If we have a data object, not created via a root object derived from a query, or from gm.emptyGraph(helper.getConfig()).createDataObject(), then how do we best persist that to the database?
Thank you
> 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
>
>
> 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