<br><div class="gmail_quote">On Sun, Apr 3, 2011 at 10:35 AM, Michael Snoyman <span dir="ltr">&lt;<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div dir="ltr">As a short term solution, I think you&#39;re right. However, I think we might want to consider a slightly more sophisticated approach... I say consider specifically, because I&#39;m really not certain that what I&#39;m saying is a good idea.<div>


<br></div><div>I think there&#39;s basically three problems with the approach of using a PersistValue inside a PersistKey:</div><div><br></div><div>1) It will probably hurt performance, since we&#39;ll need to do more checking.</div>


<div>2) The code becomes a bit more fragile. By adding this sum type to the mix, we&#39;re adding necessity for a number of checks that can fail.</div><div>3) There&#39;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.)</div>
</div></blockquote><div><br></div><div>I agree on the first two points. I think the principle behind 3 is actually a feature. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div dir="ltr">

<div><br></div><div>So here&#39;s the idea: each database backend will have an associated type for its key datatype. Then, instead of having:</div><div><br></div><div>    data Key entity = Int64</div><div><br></div><div>

we&#39;ll have</div>
<div><br></div><div>    data Key entity backend = BackendKey backend</div><div><br></div><div>(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&#39;m still concerned that it might lead to difficult-to-follow code. There&#39;s really only one way to find out, but I just wanted to bounce the idea around before diving in.</div>


<div><br></div></div></blockquote><div><br></div><div><br></div><div>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. <br>
This would be the only way to handle keys as strings or composite keys (if we want to support either) </div><div><br></div><div>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. </div>
<div><br></div><div><br></div></div>