Re: [Tm-devel] - Making Active Record instances $_SESSION storage safe when using PDO

[Bill <bi...@ki...>]

Oh crap, i never took concurrent access into consideration!!!! I will
have to think about that one a bit more....

Your suggestion of an extra db field for is_complete is a good idea. I
guess i do not like writing to the db unless the data is ready to commit.

An example of how I find persistence useful, is having a tabbed view. 
Current valid tabs are( Search , Results , View , Modify , Add ).  On
search submit a persistent db_object_array is created, which is used by
the Results, View and Modify tabs. I've not sorted out paging of results
yet, but i don't think it will be too tricky to add that in later.

The more i write the worse the code becomes ;-) no fault of TM , just my
illogical brain.

I don't really understand what you mean by separating off
PersistentActiveRecord classes, but i'm sure if you think it is a good
idea, then it is good idea :)


Bill


Michał Słaby wrote:
> On Mon, 2008-01-07 at 21:57 +0000, Bill wrote:
>   
>> Hi,
>>
>> This might be of no interest to you. But i've been finding that because
>> of the separation of code execution between the various ajax calls, i
>> needed a way to persist data objects rather than having to keep passing
>> all the parameters to instantiate the db objects every call.
>>     
>
> Actually I was considering making AR object session persistent.
> Remembering some difficulties I has in my previous job with stateful
> business logic, I decided not to do so. Sessions are hard to debug and
> writing command line test procedures is difficult.
>
> On the other hand, there is nothing wrong with session persistent AR if
> you know what you are doing and you need it. I can understand that it
> might be handy to gather information from user in several steps (like in
> wizard) and save it eventually. In such case, I personally prefer to use
> additional field in database table - is_complete boolean not null. If
> object is not complete, it is not getting displayed in user interface.
>
> Another problem you may run into using session based persistence is
> locking. If you have many users working on the same data at the same
> time, plus circumstances occur, you might end up having inconsistent
> data in db. However, if such situation happen I will ask you for
> upcoming Lotto numbers ;-)
>
>   
>> To do this
>> i have a view controller and views can then have persistent db objects
>> stored against them. This was working for adodb active record objects,
>> but i wanted to start using your active record system instead.
>>     
>
> I presume there should be a way to subclass PersistentActiveRecord from
> ActiveRecord. It could be handy to have it in core classes.
>
> (...)
>   
>> One other thing, session_start is best called after autoload.php and
>> includes.php else the constructors will not present when the stored
>> objects are unserialised!
>>     
>
> This, I reckon, will not cause any problems.
>
>
> Regards,
> Michael
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Tigermouse-devel mailing list
> Tig...@li...
> https://lists.sourceforge.net/lists/listinfo/tigermouse-devel
>
>