[Dev] removed use of defaultValue in parcel XML

[John Anderson]

As the largest user of defaultValue in parcel XML, I decide to stop 
using them for the reasons outlined below. While I was at it I removed 
them in all the parcel XML. The change had no impact on startup time 
(1:04 without a repository) (0:13 with a repository)

John

P.S. I noticed one semantic difference between defaultValue and 
initialValue. A string attribute can have a default value of None and an 
initial value can't

Katie Capps Parlante wrote:

> Hi all,
>
> We discussed initialValue and defaultValue back at the data model 
> meeting in March: 
> http://wiki.osafoundation.org/twiki/bin/view/Journal/DataModelMeeting20040311 
>
>
> In particular, the apps team argued that the client of the repository 
> (in this case, the application blocks code and content model) usually 
> wants the value to be able to show up in queries, and wants to be able 
> to modify the value if it is a mutable type (without modifying some 
> shared value). We agreed that the apps team would use initialValue, 
> and basically ignore defaultValue.
>
> I would argue that the client always wants the semantics of 
> initialValue. One could imagine an optimization to initialValue, where 
> a shared value is used until write (the item would get a copy in this 
> case). Having two options with slightly different semantics is 
> confusing, so I'd recommend that we don't expose defaultValue, and go 
> ahead and make it an error in the parcel xml. If we find ourselves 
> regretting this, we can always change it back.
>
> Cheers,
> Katie
>
> John Anderson wrote:
>
>>
>>
>> Andi Vajda wrote:
>>
>>>
>>> This proposal is a slippery slope, isn't it ?
>>
>>
>>
>> I'm a little confused why it's a slippery slope.
>>
>> In the past because of Katie's concerns, we agreed to use 
>> initialValue instead of defautValue. I started using defaultValue 
>> because it seemed more efficient, but evetually got bitten by 
>> problems, which were the same problems Katie originally articulated 
>> -- which I didn't fully understand. It seems like any benefits of the 
>> current model don't out weigh the costs in complexity, so it seems 
>> prudent to make sure nobody else falls into the same trap I did.
>>
>> John
>>
>>>
>>> Andi..
>>>
>>> On Sun, 18 Jul 2004, John Anderson wrote:
>>>
>>>> So Andi didn't go for getting rid of DefaultValue. Morgen, can we 
>>>> make it an error to use it in parcel XML?
>>>>
>>>> John
>>>>
>>>> Andi Vajda wrote:
>>>>
>>>>>
>>>>>> As Andi notes below, if you modify an attribute with a default 
>>>>>> value, and it's a mutable type, it will modify all items instead 
>>>>>> of just this one item. This seems completely nuts -- and so error 
>>>>>> prone that I can't ever imagine
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Well, you're re-phrasing this in a way that's not fair. No items 
>>>>> are modified. Modifying a mutable defaultValue would make the 
>>>>> value appear modified by all items that cause it to be returned 
>>>>> but no items are actually modified since no item actually stores 
>>>>> the defaultValue, except for the schema Attribute item.
>>>>>
>>>>> That's why the defaultValues of mutable type are marked readOnly, 
>>>>> to prevent this very error from happening. The attribute is *not* 
>>>>> marked readOnly, the actual mutable value is.
>>>>>
>>>>>> wanting to use it. As Katie pointed out to me there really isn't 
>>>>>> a reason for both defaultValues and initialValues, except for an 
>>>>>> optimization -- which the repository should hide from us anyway 
>>>>>> and not expose as an api. So I propose
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> There is a semantic difference between defaultValue and 
>>>>> initialValue that can be presented as such:
>>>>>   - defaultValue prevents an AttributeError from being raised by 
>>>>> returning a
>>>>>     default value instead, owned by the schema
>>>>>   - defaultValue really doesn't define an item's attribute value 
>>>>> but a
>>>>>     stand-in. I don't expect queries to return matched on 
>>>>> defaultValues, for
>>>>>     example. (Although it would be possible to do so, of course).
>>>>>   - initialValue is a value copied into the item upon construction 
>>>>> and that
>>>>>     copy is owned by the item
>>>>>
>>>>> There is also the space/performance trade-off. It is not an 
>>>>> optimization issue
>>>>> really, as defaultValue uses less space but takes longer to access 
>>>>> (everytime, the defaultValue is fetched from schema), whereas 
>>>>> initialValue uses more space but takes less time to access since 
>>>>> the value is copied into the item upon creation. I should also 
>>>>> point out, that liberal use of initialValue everywhere will slow 
>>>>> down item creation and item commits as these values have to be 
>>>>> written out upon save.
>>>>>
>>>>>> that we remove defaultValues from the repostory. And if Andi 
>>>>>> doesn't go for it, perhaps Morgen could make the parcel loader 
>>>>>> treat defaultValue as an error.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Which one you use depends on your usage patterns. For non mutable 
>>>>> types, the choice is really simple. For mutable types, again, the 
>>>>> choice should be simple too as the data model protects the values. 
>>>>> If you know the attribute is not going to change, defaultValue 
>>>>> should do. If you want queries to match on the values, then 
>>>>> defaultValue is not a good choice. So, there are a number of 
>>>>> decisions you could be making.
>>>>>
>>>>> If you don't want to use defaultValue, don't use it. If you can't 
>>>>> imagine ever using defaultValue, then don't; asking everyone else 
>>>>> not to, or worse, preventing everyone else from using it is a 
>>>>> little iffy.
>>>>> I use it in the core schema and it works quite well.
>>>>>
>>>>> Again, there is no danger in using defaultValue, mutable values 
>>>>> are marked readOnly by the data model, so changing a defaultValue 
>>>>> is rather complicated and shouldn't happen by acciddent.
>>>>>
>>>>> There are semantic differences that should determine which one you 
>>>>> want to use.
>>>>>
>>>>> Andi..
>>>>>
>>>>
>