[web-devel] What does Persist's PersistUpdate datatype do?
michael at snoyman.com
Sun Apr 17 07:07:19 CEST 2011
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.
>> 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 ;).
> Perhaps what I would suggest then is providing the ability to use the
> update keyword over a whole data type like so:
> 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
> 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 ;).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the web-devel