On Apr 16, 2011, at 10:53 PM, Michael Snoyman wrote:

On Sun, Apr 17, 2011 at 6:27 AM, Ian Duncan 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.

On Apr 16, 2011, at 11:48 PM, Michael Snoyman wrote:

On Sun, Apr 17, 2011 at 7:37 AM, Ian Duncan wrote:

On Apr 16, 2011, at 10:53 PM, Michael Snoyman wrote:

...

On Sun, Apr 17, 2011 at 6:27 AM, Ian Duncan 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?

Field operation annotations could be very useful for some databases that do not support ad-hoc queries. However, all persistent databases currently do support ad-hoc queries. So the benefit is that indexes could be auto-generated. I am skeptical of this though- unless one is using a very aggressive indexing strategy, there isn't enough information to determine indexes. So really these annotations could be helpful to manually determine indexes. Another problem is the compiler will tell me to add a field operation that enables an operation, but I am likely to forget to remove the annotation if things are later changed and it is no longer needed. The concept of declaring indexes is important, but perhaps we would be better off adding actual index annotations to persistent. Either way I think it would be best to provide a new quasi-quoter that does not require field operation annotations. Greg Weber On Sat, Apr 16, 2011 at 10:07 PM, Michael Snoyman wrote:

On Sun, Apr 17, 2011 at 8:01 AM, Ian Duncan wrote:

...

On Apr 16, 2011, at 11:48 PM, Michael Snoyman wrote:

On Sun, Apr 17, 2011 at 7:37 AM, Ian Duncan wrote:

...

On Apr 16, 2011, at 10:53 PM, Michael Snoyman wrote:

On Sun, Apr 17, 2011 at 6:27 AM, Ian Duncan 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

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel