Page 4 of 4
Re: Ideas for lightweight ORM implementation
Posted: Wed Dec 02, 2009 9:44 pm
by josh
arborint wrote:The lock would only provide locking when accessing the data through the ORM
Personally if I were using said framework I would rather not have that decision made for me. Maybe there's a legitimate circumstance I would want to bypass that lock. Maybe I want to make a "save anyways" prompt for the user (in the event his co-worker passed away prior to checking the locked file back in). Also the way you track the owners of the locks would have to be accommodating, who says my situation is as simple as locks being owned by a single user_id?
Re: Ideas for lightweight ORM implementation
Posted: Thu Dec 03, 2009 12:34 am
by Christopher
PCSpectra wrote:OK how does object level locking differ from row-level locking here? Row-level locking lasts for the duration of the script execution I imagine, whereas I supposed one could implement object locking and persist the lock in the database, but that requires storing meta data somewhere.
Usually the locks are stored in a data table.
PCSpectra wrote:I'm not sure I would personally want that implemented at the PHP level (or at least ORM), for starters it's not consistent across the board. Yes someone might edit a record which I am also working on (I think this is a basic compromise most developers are willing to accept and thus clients are assumed to as well -- but anyways) however there is nothing to stop say phpMyAdmin from circumventing this lock, correct?
Whether you want to personally or whether your clients are willing to accept overwritten data occasionally is irrelevant. Likewise if you start updating data in a database to which an app is writing.
PCSpectra wrote:If you need to prevent concurrency such as the case in mission critical software: PHP on the web is *maybe* not the right tool for the job.
I hope you understand how crazy that statement is...
PCSpectra wrote:I would argue this feature is somewhat 'rocket' like in intent, in that you need an all or nothing solution, not something half-fast. I wouldd rather find some alternative solution, such as establish a persistent connection, store the resource in shared memory and use transactions and row-level locking to truly enforce this policy.
There really isn't another solution. Are you going to delete the records you are editing, copy them to shared memory and then insert when done? So now they can't be read while being edited?
Honestly, I think the reason that overwriting is tolerated is that no one has written a simple system that implements Offline Locks. Doing that is part of our plan. It would make it easy to write CRUD or wizards that locked the data for that user. And make it easy to detect that the data was locked to provide an error message.
Re: Ideas for lightweight ORM implementation
Posted: Thu Dec 03, 2009 12:44 am
by Christopher
josh wrote:Personally if I were using said framework I would rather not have that decision made for me. Maybe there's a legitimate circumstance I would want to bypass that lock. Maybe I want to make a "save anyways" prompt for the user (in the event his co-worker passed away prior to checking the locked file back in). Also the way you track the owners of the locks would have to be accommodating, who says my situation is as simple as locks being owned by a single user_id?
Don't know what "said framework" is? I don't recall anywhere saying that any decisions would be made for anyone. They certainly could if you wanted them to be, but I don't see why the system needs to enforce anything? If you want something to use locks then request/check for a lock when you fetch the object. It would be up to you whether to honor the lock. I assume there is a timestamp so that you can check if the record is abandoned. It would not be too difficult to write any custom overrides you wanted. But you are getting way ahead of yourself.

Re: Ideas for lightweight ORM implementation
Posted: Thu Dec 03, 2009 6:13 am
by josh
Yeah just throwing a few advanced use cases out there. I think you are right the lock manager must implement an interface that allows polling it for timestamps and forcing the lock to be released and such. It should have swappable strategies or adapters for identifying lock owners
Re: Ideas for lightweight ORM implementation
Posted: Thu Dec 03, 2009 2:41 pm
by Christopher
Yes. Given the large number of possible custom scenarios, it seems like other than the simplest case it should probably be up to the programmer to supply the unlocking/override logic. If the system could provide information like the locker's ID and a timestamp, then the programmer could implement exactly the functionality they want.
I think a Offline Lock library would be a useful standalone library as well. I think it should be built as such. There are many cases outside of an ORM where an easy-to-use lock system would handy (such as the CRUD and queue examples I gave above). Hopefully you will hold onto those ideas for when we get to that point!

Re: Ideas for lightweight ORM implementation
Posted: Thu Dec 03, 2009 4:38 pm
by josh
Hmm you could have an automatic lock release timeout setting people could opt to use
Re: Ideas for lightweight ORM implementation
Posted: Thu Dec 03, 2009 6:19 pm
by Christopher
Yes, I think there could and should be a set of sane defaults to make the thing just work. But they should be easily overridden by settings or even additional parameters to the lock checking methods.
Re: Ideas for lightweight ORM implementation
Posted: Thu Dec 03, 2009 6:46 pm
by alex.barylski
I hope you understand how crazy that statement is...
It's why I emphasized *maybe*
Whether you want to personally or whether your clients are willing to accept overwritten data occasionally is irrelevant
Why is it irrelevant.
There really isn't another solution. Are you going to delete the records you are editing, copy them to shared memory and then insert when done? So now they can't be read while being edited?
Really, if that is the case then I suppose it makes sense. I have never had to implement such a feature, although admittedly I have anticipated such a request, it`s never been critically required.
The only instance I can think of where this was an issue was with an actively used CMS where many editors were constantly modifying pages, but the client eventually concluded that version control was the prefered solution, I tend to agree.
As I understand the basics of row and table locking, how is this any different, assuming one uses a persistent connection...
Honestly, I think the reason that overwriting is tolerated is that no one has written a simple system that implements Offline Locks. Doing that is part of our plan. It would make it easy to write CRUD or wizards that locked the data for that user. And make it easy to detect that the data was locked to provide an error message
Obviously, if the functionality was native to RDBMS I would use it, but its rare that concurrency issues arise and the implementation is probably complex. My reasoning, is simply that, if a client requested this feature, it would probably be mission critical requirement, more than a feature enhancement.
In those cases, would you really want a PHP ORM handling this for (obviously you would -- obviously I wouldnt...LOL) you or would you not look for an enterprise solution, such as row level locking in a RDBMS, that is my only point. Not suggesting the idea ispointless or useless, etc. By all means implement it it might come in handy for me one day -- and I'll send you donation or something:P
Cheers,
Alex
Re: Ideas for lightweight ORM implementation
Posted: Thu Dec 03, 2009 7:15 pm
by Christopher
PCSpectra wrote:In those cases, would you really want a PHP ORM handling this for (obviously you would -- obviously I wouldnt...LOL) you or would you not look for an enterprise solution, such as row level locking in a RDBMS, that is my only point.
Half of your argument is that you shouldn't solve this problem in PHP; the other half is that you don't see a need for it. I am still missing how PHP code cannot be an enterprise solution and row level locking in a RDBMS is? To me, an enterprise solution is anything that solves an enterprise problem.
Re: Ideas for lightweight ORM implementation
Posted: Thu Dec 03, 2009 9:24 pm
by alex.barylski
Half of your argument is that you shouldn't solve this problem in PHP; the other half is that you don't see a need for it. I am still missing how PHP code cannot be an enterprise solution and row level locking in a RDBMS is? To me, an enterprise solution is anything that solves an enterprise problem.
PHP can offer enterprise solutions, absolutely, that is not my point. My point is, I guess it's best implemented at the RDBMS layer/level not PHP. It's akin to implementing a SQL based RDBMS in PHP just in case your shared server doesn't have MySQL installed.
While it would be neat, it seems like a classic case of over engineering, when in those rare cases where it's not available or absolutely required, it's less work to just find a different host, or in this case, use a RDBMS that supports row level locking and use persistent connections, etc. Unless it is not technically possible while running PHP under a web environment; In which case I would again argue perhaps at this point, PHP is not the right tool for the job?!?
Cheers,
Alex
Re: Ideas for lightweight ORM implementation
Posted: Fri Dec 04, 2009 7:54 am
by josh
PCSpectra wrote:Why is it irrelevant.
because I consider it relevant
Its not the same as row level locking, as already stated (well maybe if you use Active Record), but maybe thats just another case where what is relevant to you is not the same as what is relevant to me.
You don't want to lock the row to the whole system, you just want to enforce a lock on an object (which maybe be multiple rows from multiple tables). It doesn't make sense to have 100,000s of thousands of RDMS locks floating around.
Maybe you are confused as to how this works. Go check out dreamweaver's free trial, set up an FTP site and enable file check in and check out. It is so business users can collaborate without fear or overwriting each other's changes (when no audit system is in place). If You lock a file and I try to download it it gives me a warning that you are working on local changes that have not been committed.
Personally I would much rather have an audit system, but it couldn't hurt to have both an audit trail and an offline lock in place.
Re: Ideas for lightweight ORM implementation
Posted: Fri Dec 04, 2009 7:57 am
by inghamn
I think this type of locking is best handled in the controller, instead of an ORM feature. We're talking about something like a CMS where you want to make sure that people cannot edit stuff at the same time. This is to keep unintended overwrites down. The web being stateless, the possibility of a person just closing the browser in the middle of editing something, and other things conspire to make this difficult.
None of these challenges deal with something a database should be expected to know about.
If you're using a database, it is responsible for data integrity. Meaning, the database is responsible for always preserving what you send it. An application's session-level lock on a large swath of stuff is really outside the real of what the database can be expected to provide. Even with row-level locking, the database is correctly going to preserve multiple subsequent data updates. The last one wins, but each update is locked, updated, and released (all very very quickly).
I'm proposing that the CMS-multiple-people-editing type of lock is really flow control for the web application, which is the realm of controller responsibilities.
Re: Ideas for lightweight ORM implementation
Posted: Fri Dec 04, 2009 8:00 am
by josh
inghamn wrote:I think this type of locking is best handled in the controller, instead of an ORM feature.
Well I agree, it would likely belong to the the ORM, but the API would need to be explicit and in the controller where I can see it. No magic creepy side effects.
Code: Select all
$model = $orm->usingOfflineLock()->find( 1 );
$orm->usingOfflineLock()->save( $model )
(one possible fluent interface to it, to keep it visible in controllers)
or..
Code: Select all
$setting = array( 'overrideAll' => true ); // ignore locks and force a save()
$orm->usingOfflineLock( $setting )->save( $model )
Re: Ideas for lightweight ORM implementation
Posted: Fri Dec 04, 2009 8:13 am
by inghamn
josh wrote:
Code: Select all
$model = $orm->usingOfflineLock()->find( 1 );
$orm->usingOfflineLock()->save( $model )
This still assumes you're locking something in the model. I'm saying that what you actually want to lock in this case is the controller's action. In our CMS, when a user is editing a page, there's several models involved. It's the controller action that knows which pieces of what models are being affected.
The goal is to make sure users cannot edit the same stuff at the same time. Don't focus on the stuff. It's the editing that you're wanting to control. It's like another form of ACL
Re: Ideas for lightweight ORM implementation
Posted: Fri Dec 04, 2009 8:23 am
by alex.barylski
Its not the same as row level locking, as already stated (well maybe if you use Active Record), but maybe thats just another case where what is relevant to you is not the same as what is relevant to me.
How is it different from row-level locking, other than it allows persistence across requests, in which case if you used persistence questions, etc would it not be the same?
You don't want to lock the row to the whole system, you just want to enforce a lock on an object (which maybe be multiple rows from multiple tables). It doesn't make sense to have 100,000s of thousands of RDMS locks floating around.
I don't think using row-level would result in anything different than ORM object level locking, if implemented to solve the same problem.
As I understand (of row-level locking):
1. Establish persistant connection
2. Lock rows X through Y
3. Allow user to enter data into form
4. Upon saving, release the row level locks
The major difference I see is that of connection pooling, having to persist arbitrary connections as opposed to letting the platofmr it self perform cleanup at script end.
Maybe you are confused as to how this works. Go check out dreamweaver's free trial, set up an FTP site and enable file check in and check out. It is so business users can collaborate without fear or overwriting each other's changes (when no audit system is in place). If You lock a file and I try to download it it gives me a warning that you are working on local changes that have not been committed.
Row-level locking or ORM? I have read a few articles now on row-level locking and while I'm sure the implementation isn't trivial the basics of the mechanism and it's use are certainly not rocket science.
ORM as I understand locks the rows regardless of what connection attempts to mutate the data, which row-locking should achieve as well, with a persist connection I assume.
Cheers,
Alex