Re: DiskFile not cloned when published

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/tr=
ac/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?)

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