[web-devel] (Yesod) PersistEntity Key types

[Greg Weber]

On Sun, Apr 3, 2011 at 7:44 AM, Rick Richardson
<rick.richardson at gmail.com>wrote:

>
> On Sun, Apr 3, 2011 at 10:35 AM, Michael Snoyman <michael at snoyman.com>wrote:
>
>> As a short term solution, I think you're right. However, I think we might
>> want to consider a slightly more sophisticated approach... I say consider
>> specifically, because I'm really not certain that what I'm saying is a good
>> idea.
>>
>> I think there's basically three problems with the approach of using a
>> PersistValue inside a PersistKey:
>>
>> 1) It will probably hurt performance, since we'll need to do more
>> checking.
>> 2) The code becomes a bit more fragile. By adding this sum type to the
>> mix, we're adding necessity for a number of checks that can fail.
>> 3) There's nothing stopping you from inserting a value into one database
>> (say, SQLite), getting a key, and then looking up in MongoDB. (Not that this
>> is a flaw in the current approach as well.)
>>
>
> I agree on the first two points. I think the principle behind 3 is actually
> a feature.
>
>
>>
>> So here's the idea: each database backend will have an associated type for
>> its key datatype. Then, instead of having:
>>
>>     data Key entity = Int64
>>
>> we'll have
>>
>>     data Key entity backend = BackendKey backend
>>
>> (ignoring all the newtype wrappers). I think this should solve both the
>> issue you raise about MongoDB, and the three points I mention above.
>> However, I'm still concerned that it might lead to difficult-to-follow code.
>> There's really only one way to find out, but I just wanted to bounce the
>> idea around before diving in.
>>
>>
>
> I am going to negate my previous email. After thinking on this a bit. I
> think that setting they key type at the PersistEntity is the correct
> approach.
> This would be the only way to handle keys as strings or composite keys (if
> we want to support either)
>

There are 2 use cases- relying on MongoDB to auto-generate a key, or
providing one's own key. Now technically the key provided could be almost
any PersistValue. But I think in practice it is likely to be an integer or
an ObjectId. And I think even those use cases are likely to be the
exception, not the rule. For now, to get this working, I think it is
reasonable to assume that no id value will be provided by the user- that
mongoDB will always be auto-generating it. So we should be able to
just accommodate the key the same way as a normal db, except that it is 12
bit number. And then it should be easy to go from there to support the user
supplying their own ObjectId (which is the 12 bit number that MongoDB
auto-generates). And supporting inserting an integer with the overhead of
assuming it is 12bits would be easy also.


> If we want to restrict all Yesod databases to a single pre-defined key type
> per database, then I will implement your solution.  If we want to be
> flexible (for legacy database support) then I think we should go with a
> parameterized type solution, and I have no idea how to make it efficient.
>
>
>
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20110403/f1742e75/attachment.htm>