Racinet Georges | 21 Jun 12:12
Picon

Re: DiskFile not cloned when published


On Jun 18, 2009, at 1:21 PM, Racinet Georges wrote:

>
> On Jun 18, 2009, at 12:34 PM, Christophe Combelles wrote:
>
>> Racinet Georges a écrit :
>>> On May 19, 2009, at 4:21 PM, Christophe Combelles wrote:
>>>> Christophe Combelles a écrit :
>>>>> Racinet Georges a écrit :
>>>>>>
>>>>>> On May 12, 2009, at 5:40 PM, Christophe Combelles wrote:
>>>>>>
>>>>>>> Thanks, I've finally backported some fixes for StorageAdapter,  
>>>>>>> which was overwriting too many fields during a document update.
>>>>
>>>> There is a remaining bug with DiskFile, even on CPS 3.4.8.
>>> Thanks for the report, Christophe.
>>> Such detailed issue should belong int the trac : http://svn.nuxeo.org/trac/pub 
>>>  (log in as tracguest/tracguest)
>>> If you eventually have a patch for this, I'd be glad to check it in.
>>
>>
>> The corresponding ticket in the tracker is
>> http://svn.nuxeo.org/trac/pub/ticket/1998
>>
>> Did you have time to try a solution? (I didn't yet).
>
> Neither did I :-(
>
>> Is datamodel._set_editable the way to go?
>
> I don't think so, because if validation fails in another widget,  
> then the change in title will be nevertheless commited (in the new  
> version).
>
> A quick and a bit dirty solution would be to postpone this :  
> DataModel could keep track of File title changes and apply them in  
> dm._commit()
> Something like datamodel.changeFileTitle(key, title) instead of  
> datamodel[key].title = title. Now DataModel has to be smart enough to
> understand that such a change is obsoleted by a change of the whole  
> File object, but that's do-able.
>
> The main advantage of this approach is that it's less risky  
> (regression, memory problems) than populating the datamodel with  
> shallow copies of file objects (what would happen with subobjects,  
> btw?)

Finally I implemented the insulating approach. That seems to solve the  
issue (could see that it had impact on regular files as well)
Now let's use trac only for follow ups

>
> What do you think ?
>
>
>
>>
>>
>>
>>>>
>>>>
>>>> Christophe
>>>>
>>>>
>>>>>>
>>>>>> Wow, I remember those fixes, one of the last generic work on  
>>>>>> CPS I've done as a Nuxeo employee,
>>>>>> The primary goal was to avoid useless writes in LDAP backing  
>>>>>> directories, while still being able to update a meta directory  
>>>>>> upstairs (for CPS specific fields that would be stored in  
>>>>>> another - ZODB - backing).
>>>>>>
>>>>>> Did you backport this on your project for directories or  
>>>>>> documents ? I've always wondered what the overall (positive, I  
>>>>>> hope) performance impact in the case of documents would be, and  
>>>>>> never had a chance to measure that.  Any numbers to share ?
>>>>> I've backported it for CPSDocuments, to avoid dataloss with  
>>>>> DiskFile objects overwriting an already  published file. This is  
>>>>> not related to performance so I didn't measure anything.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> -- 
>>>>>> Georges Racinet, http://www.racinet.fr
>>>>>> Zope/CPS/Plone expertise, assistance & development
>>>>>> GPG: 0x4862FFF7
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> cps-devel mailing list
>>>>>> http://lists.nuxeo.com/mailman/listinfo/cps-devel
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> cps-devel mailing list
>>>>> http://lists.nuxeo.com/mailman/listinfo/cps-devel
>>>>
>>>> _______________________________________________
>>>> cps-devel mailing list
>>>> http://lists.nuxeo.com/mailman/listinfo/cps-devel
>>> -- 
>>> Georges Racinet, http://www.racinet.fr
>>> Zope/CPS/Plone expertise, assistance & development
>>> GPG: 0x4862FFF7
>>> _______________________________________________
>>> cps-devel mailing list
>>> http://lists.nuxeo.com/mailman/listinfo/cps-devel
>>
>> _______________________________________________
>> cps-devel mailing list
>> http://lists.nuxeo.com/mailman/listinfo/cps-devel
>
> --
> Georges Racinet, http://www.racinet.fr
> Zope/CPS/Plone expertise, assistance & development
> GPG: 0x4862FFF7
>
>
>
>
>
>
>
> _______________________________________________
> cps-devel mailing list
> http://lists.nuxeo.com/mailman/listinfo/cps-devel

--
Georges Racinet, http://www.racinet.fr
Zope/CPS/Plone expertise, assistance & development
GPG: 0x4862FFF7

_______________________________________________
cps-devel mailing list
http://lists.nuxeo.com/mailman/listinfo/cps-devel


Gmane