Thought inc.

The Dynamic O/R Mapping Company
     

CocoBase Technical Support Forums
For access to developer site with software download and doc's, please request CocoBase download and password
will be emailed to you. Response to posts will appear when answered by THOUGHT Support team.
NOTE:You must register separately with forum in order to post your questions, please click on register icon below.
Home   Frequently Asked Questions   Search   Edit your profile   Registration is free!  
Email This Page to Someone!
Show a Printable Version
CocoBase Enterprise O/R Forums > CocoBase Suggestions
Safer delete behavior
< Previous Thread     Next Thread >
Author
Thread    Post New Thread     Post A Reply
steve
Member

Registered: May 2001
Posts: 16

There are many places in Cocobase where the mapping layer will silently fail to correctly map statements and objects due to incorrect data in the maps (from a typo in the field name, for example). I suppose some people might consider this a feature, but one place it's especially dangerous is in delete statements. If there is an error in the where clause specification, Cocobase will happily proceed to delete ALL data in the table. I'd recommend that if any where clauses are specified for a delete statement that Cocobase considers it an error if no where clause information is generated in the SQL statement. In this case, the user probably intended to perform a limited delete and the general delete operation is the result of an application or map error. If map-level options are ever supported in the admin tool, the user could explicitly override the safer behavior for a specific map if they needed to do so. If no where clauses are specified for the delete statement, then allow the general delete operation without requiring an override.

05-24-2001 01:29 PM
Click Here to See the Profile for steve    Find more posts by steve        Edit/Delete Message    Reply w/Quote    IP: Logged
admin
Administrator

Registered: Apr 2001
Posts: 19

Actually customers want this behavior and it's there because
it should be. One way to safeguard your application from
inadvertant or suprise deletes would be to check the record
count to make sure it's not more than it should be. The number
of records deleted are returned automatically from the call to
delete and you can check the results to confirm that the
correct number were affected...

You can also accomplish similar tasks including the ability to
confirm & validate your Maps through the plugin interface as
well...

We'll also file a request with the developers to see if there
are any additional options that can be provided in a more
automated fashion. What we can tell you is that customers
have used wildcard deletes and updates in the past and it is
a desirable feature by many to be able to issue any SQL
including SQL with no where conditions.

THOUGHT Support

05-24-2001 03:05 PM
Click Here to See the Profile for admin    Find more posts by admin        Edit/Delete Message    Reply w/Quote    IP: Logged
steve
Member

Registered: May 2001
Posts: 16

Hi, and thanks for the response. If you'll reread my suggestion you see that I did not suggest removing or restricting intentional "wildcard" (unconstrained) deletes which would be indicated by a lack of where clause definitions in the map's delete definition. I suggested providing safeguards when the user has provided where clause definitions in the map and none of the where clauses are included in the generated SQL. This can happen if there is a typo in the fieldname, for example. Again, the where clause has been defined in the map, but there is a minor error so it's not included in the SQL. Currently, the result is that all the table's rows are deleted, silently and without warning. Somehow I doubt that customers are asking for that "feature". Regarding the suggested workarounds... How would I check the number of rows deleted? In the scenario I'm describing, I would be binding a single object to the transaction using binddelete. When the Cocobase transaction commits at level 0, the transaction will commit the JDBC connection via the Cocobase driver and delete *all* the rows since the where clause(s) would be ignored (again, due to a minor map error in this scenario). How do I get the result value from the JDBC executeUpdate() several layers below the Cocobase transaction commit call? I can look into using the plugin interface to do map validation for this issue, but I thought that this was such a general problem with potential distrastrous side-effects that Thought might consider it as a product feature.

05-24-2001 05:51 PM
Click Here to See the Profile for steve    Find more posts by steve        Edit/Delete Message    Reply w/Quote    IP: Logged
admin
Administrator

Registered: Apr 2001
Posts: 19

We agree that ways to 'check' for an unintentional delete
would be useful. In fact we have a sample plugin that we
used to install into the 3-tier mapping server (it could
also be modified to be used by the 2-tier runtime) that would
look for field properties and reject the delete operation
if there was no data. This could be modified to specifically
check for FIELD_LABEL matches with minimal code - and a sample
plugin or 'property' to enable this is certainly good to
include - we won't argue with that.

Now as for 'workarounds' that you can easily accomplish today.
To find out how many rows were deleted, you can use the
return value from the CocoDriverInterface.delete call. If
you are using a Transaction object the only way to trigger a
delete that you didn't intend would be through the plugin
architecture.

In general we let the developers control this, and once a
map is configured the field labels shouldn't change so the
error you're describing is a 'development' oriented problem
as opposed to a deployment problem - but we do understand
the seriousnous of it.

One thing that was discussed by the developers at one point
was to put in a cocoprop runtime flag that might look like
'reject.wildcard.changes' which would reject any wildcard
operations on update or delete. This would be a 'connection
wide' change to the runtime - but it actually wouldn't be
difficult to implement.

If you speak to your salesperson they might actually be able
to get it prioritized for the next service pack. They are
pretty efficient at influencing development on issues that
support customers in their purchase...

THOUGHT Support

05-24-2001 06:51 PM
Click Here to See the Profile for admin    Find more posts by admin        Edit/Delete Message    Reply w/Quote    IP: Logged
All times are PST (US)    Post New Thread     Post A Reply
Forum Jump:
< Previous Thread     Next Thread >

Forum Rules:
Who Can Read The Forum? Any registered user or guest.
Who Can Post New Topics? Any registered user.
Who Can Post Replies? Any registered user.
Changes: Messages can be edited by their author. Messages can be deleted by their author.
Posts: HTML code is OFF. Smilies are OFF. vB code is OFF. [IMG] code is OFF.

Admin Options:
Open / Close Thread
Move Thread
Delete Thread
Edit Thread

< Contact Us - THOUGHT Inc. >

Copyright © Jelsoft Enterprises Limited 2000.
Copyright 2001 All Rights Reserved, THOUGHT Inc.