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 =E9crit :
>>> On May 19, 2009, at 4:21 PM, Christophe Combelles wrote:
>>>> Christophe Combelles a =E9crit :
>>>>> Racinet Georges a =E9crit :
>>>>>>
>>>>>> 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/t=
rac/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 =3D 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