21 Jun 12:12
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
>
>> 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,
RSS Feed