[web-devel] What does Persist's PersistUpdate datatype do?

[Michael Snoyman]

On Sun, Apr 17, 2011 at 8:01 AM, Ian Duncan <iand675 at gmail.com> wrote:

>
> On Apr 16, 2011, at 11:48 PM, Michael Snoyman wrote:
>
>
>
> On Sun, Apr 17, 2011 at 7:37 AM, Ian Duncan <iand675 at gmail.com> wrote:
>
>>
>> On Apr 16, 2011, at 10:53 PM, Michael Snoyman wrote:
>>
>>
>>
>> On Sun, Apr 17, 2011 at 6:27 AM, Ian Duncan <iand675 at gmail.com> wrote:
>>
>>> I'm fiddling around a bit with the Persist library and wondering what the
>>> PersistUpdate datatype does. From what I can gather, it looks like Update
>>> replaces the value, add will add to the current value if it is an integer or
>>> double, and subtract, multiply, and divide perform their respective
>>> operations. Is this correct, or is there something else to these types?
>>>
>>>
>> Nope, that's it. In SQL, none of the
>> addition/subtraction/multiplication/division logic is performed in
>> Persistent, rather it's all passed off to the SQL engine. So if you try to
>> divide two strings, the result depends on what the SQL engine allows.
>>
>> Michael
>>
>>
>> If I may ask then, does not using the Update keyword in the quasiquoting
>> syntax simply mean that no default implementation of update is provided? Is
>> the rationale for this to prevent accidental modifications of fields that
>> should remain static once a row is inserted? It seems like a somewhat
>> cumbersome restriction.
>>
>
> I'll tell you the theory for requiring the Update keyword (and Eq, Lt, Gt,
> Asc, Desc, ...). In theory, backends can optimize for different use cases.
> The prime example I give is that a SQL backend could automatically add
> indices if it knows that a field will be sorted on. (We don't do this
> currently, but I'll consider adding it in the future.) It's entirely
> possible that there are backends for which a more optimal structure can be
> set up when only certain fields can be updated.
>
> That's the theory. Maybe in practice this was all a bad idea, feel free to
> let me know how you feel either way ;).
>
> Michael
>
>
> Perhaps what I would suggest then is providing the ability to use the
> update keyword over a whole data type like so:
>
> [persist|
> Appointment Update
>  day Day
> time TimeOfDay
> finished Bool
> price Int Add
>  billingFirstName String
> billingLastName String
> billingTelephone String
>  billingEmail EmailId
> expressToken String NoUpdate
> expressId String NoUpdate
> |]
>
> This is a contrived example, but notice the use of the Update keyword after
> Appointment and the use of NoUpdate keyword for expressToken and expressId.
> This would make all fields updatable by default with the exception of
> expressToken, expressId, which would not provide an updating function, and
> price which would override the overwrite form of update in favor of
> addition.
>
> What do you think?
>

I have no objections, and it's a relatively easy change to put into place.
Does anyone else have an opinion?

This will likely need to wait for a point release of persistent, since I'm
really trying to avoid adding bugs 5 hours before a release ;).

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20110417/d7a689d8/attachment.htm>