Well, let's discuss the motivations for requiring the annotations at all. I *think* no one but me really knows why I did this, because I have neither documented my intentions nor taken advantage of them code wise. While it's true that it lowers the number of constructors created at compile time, that was *not* my primary concern. The idea was to allow for optimizations: for a SQL backend, the SQL migration code could produce indices automatically. For other backends, it could have an even more dramatic effect on how the data is stored. But I think that argument doesn't really apply to an IdIn constructor. Greg, I like your proposal of including it by default. If there are no objections, let's try to get it in for the next release. One other note about the next Persistent release: we're going to be splitting the package up into a core and a Template Haskell set. Some people are using Persistent in an iPhone app, and the iPhone compiler cannot support TH. Just a little heads-up. Michael On Sat, Mar 12, 2011 at 9:27 PM, Greg Weber wrote:

It might be better to save the space after the table line just for future table annotations. Then to annotate id, it would be added as a field. This brings up another point though- do we need to add "In" annotation- why not just enable it? Does it make the compiles take really long, etc? We should at least document the rational in the persistent section. On Sat, Mar 12, 2011 at 10:46 AM, Michael Snoyman wrote:

...

On Sat, Mar 12, 2011 at 3:07 AM, Katsutoshi Itoh wrote:

...

Hi

I had often wanted FooIdIn, FooIdEq on Foo Persistent type. Would you support this by default?

from japan.

As Max said, glad to see that you're safe.

For FooIdEq: I don't think there is any need, since it can be expressed more succinctly with the "get" function. As for FooIdIn: this *was* a recently requested feature. Maybe we can get it in for the next release. I think it would make sense to add the In attribute to the entity itself, eg:

mkPersist [$persist| Person In    name String    age Int |]

Any objections?

Michael

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