Hi John,
on second reading of your post,
where/how is the optimistic locking implemented -
if meant in the sense of conflict managment/resolultion -
not talking about simple "last write wins" <g>?
Is that something you have implemented for your apps,
similar to the vfp options of timestamp or changed fields only ?
Still, if you add pessimistic locks the code for delete SQL
I guess in dCursorMixin (based on my half year old version...)
the bottom of delete should probably be:
if pk in self._newRecords:
res = True
del self._newRecords[pk]
else:
pkWhere = self.makePkWhere()
# some backends(PostgreSQL) don't return information about
number of deleted rows
# try to fetch it before
sql = "select count(*) as cnt from %s where %s" %
(self.Table, pkWhere)
aux = self.AuxCursor
aux.execute(sql)
res = aux.getFieldVal('cnt')
if res:
sql = "delete from %s where %s" % (self.Table, pkWhere)
- aux.execute(sql)
+ res=aux.execute(sql)
if not res:
# Nothing was deleted
self.BackendObject.noResultsOnDelete()
# The 'res' could be empty in multiuser environment and there is
no concurrency
# control, so we delete the record from the current data set
unconditionally.
if pk in self._mementos:
del self._mementos[pk]
self._removeRow(delRowNum)
to be more in the line of the update-causing __SaveRow
and then raise the exception:
otherwise the res will stay true if there are records to be deleted
and self.BackendObject.noResultsOnDelete() will not get called ??
I am not firm enough on DABO inner workings to estimate if there can be
further unwanted effects deleting the memento and cursorRow even if
SQL-delete
did not happen: this might stem from another user having deleted in-between
getting the count and the actual execute(sql) or a lock on the row,
which might then
still be alive in the backend. From a client-side view the second might
be incorrect,
but cause seldom or no problems - OTOH any difference between a client
and backend
seems like a bad idea unless it revolves around unsaved changes/newrecs.
Perhaps Ed or Paul can jump in and clarify.
regards
thomas
John Fabiani schrieb:
> On Monday, October 31, 2011 05:40:25 am Thomas Ganss wrote:
>
>> Hi John,
>>
>> I recently scanned the code to get an idea of the changes necessary to
>> implement
>> a basic conflict resolution at least on time stamps.
>>
>> The code to delete back then AFAIR did not check if SQL-delete was
>> successful.
>> If my visualization was correct, any rowlock could then probably be
>> problematic,
>> as the biz layer would be out of synch with the backend.
>>
>> I did not check if exeptions were raised if/when delete from DABO fails
>> due to rows locked, which I could have done via backend interface...
>>
>> regards
>>
>> thomas
>>
>
> In my case I'm using Postgres and have Advisory Locks available. I having
> been thinking I could use some/all of the bizObj.beforexxxx() hook methods to
> check on the advisory lock. That said I was hoping for more discussion on
> the
> matter because I know others must have similar needs of the Dabo framework.
>
> Johnf
> _______________________________________________
> Post Messages to: [email protected]
> Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
> Searchable Archives: http://leafe.com/archives/search/dabo-users
> This message:
> http://leafe.com/archives/byMID/[email protected]
>
>
--- StripMime Report -- processed MIME parts ---
multipart/alternative
text/plain (text body -- kept)
text/html
---
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/[email protected]
