<p>How about generating a version of the records lifted to Maybe? </p>
<div class="gmail_quote">Am 06.05.2011 04:03 schrieb "Max Cantor" <<a href="mailto:mxcantor@gmail.com">mxcantor@gmail.com</a>>:<br type="attribution">> Personally, I vote against this. Putting in undefineds maintains type-safety. However, in my mind the primary purpose of static type-safety is the avoidance of runtime errors. This only encourages that. Perhaps a better approach is to have some a TH function to generate "subselects" which would be records that only contain the requested data. Its a bit more constraining, but I fear that the alternative is tantamount to curing the disease by killing the patient.<br>
> <br>> furthermore, I worry that allowing undefined's here will start a slippery, runtime-error-laden slope which we're better off avoiding..<br>> <br>> max<br>> <br>> <br>> <br>> On May 5, 2011, at 9:55 PM, Michael Snoyman wrote:<br>
> <br>>> That's interesting: I'd never considered the idea of inserting<br>>> undefined into fields you want excluded... That could work. The reason<br>>> I've avoided putting in this (often requested) feature is that I could<br>
>> think of no way to do so and keep type safety. That might be an<br>>> approach.<br>>> <br>>> We may consider requiring the user to supply the value instead,<br>>> thereby avoiding the library inserting undefined.<br>
>> <br>>> Michael<br>>> <br>>> On Thu, May 5, 2011 at 4:32 PM, Greg Weber <<a href="mailto:greg@gregweber.info">greg@gregweber.info</a>> wrote:<br>>>> An alternative to laziness would be selecting a subset of fields. There is<br>
>>> no support for this directly in persistent, but it might be possible to add<br>>>> it and the future and have the value of an unselected field be something<br>>>> like undefined.<br>>>> At the moment you can select sub fields by dropping down to lower-level sql<br>
>>> methods (ask Michael about these methods if you are interested). I think<br>>>> there is a technique for building your persistent data structure back up<br>>>> from the return of raw sql, which again you might be able to do by inserting<br>
>>> dummy error fields.<br>>>> Greg Weber<br>>>> <br>>>> On Thu, May 5, 2011 at 4:18 AM, Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>> wrote:<br>>>>> <br>
>>>> On Thu, May 5, 2011 at 1:28 PM, Felipe Almeida Lessa<br>>>>> <<a href="mailto:felipe.lessa@gmail.com">felipe.lessa@gmail.com</a>> wrote:<br>>>>>> On Thu, May 5, 2011 at 2:20 AM, Jeremy Hughes <<a href="mailto:jedahu@gmail.com">jedahu@gmail.com</a>> wrote:<br>
>>>>>> Is Database.Persistent lazy wrt reading fields? I need to iterate over<br>>>>>>> entities containing both small and large fields. I do not need to use<br>>>>>>> the large fields in this instance, and so would rather they were not<br>
>>>>>> read from the database.<br>>>>>> <br>>>>>> IIRC, they are read strictly. I guess you should put them on a<br>>>>>> different entity.<br>>>>> <br>
>>>> That's correct. In fact, Persistent avoids any form of lazy I/O to<br>>>>> ensure that database connections are returned to the pool as soon as<br>>>>> possible (amongst other reasons).<br>
>>>> <br>>>>> Michael<br>>>>> <br>>>>> _______________________________________________<br>>>>> web-devel mailing list<br>>>>> <a href="mailto:web-devel@haskell.org">web-devel@haskell.org</a><br>
>>>> <a href="http://www.haskell.org/mailman/listinfo/web-devel">http://www.haskell.org/mailman/listinfo/web-devel</a><br>>>> <br>>>> <br>>> <br>>> _______________________________________________<br>
>> web-devel mailing list<br>>> <a href="mailto:web-devel@haskell.org">web-devel@haskell.org</a><br>>> <a href="http://www.haskell.org/mailman/listinfo/web-devel">http://www.haskell.org/mailman/listinfo/web-devel</a><br>
> <br>> <br>> _______________________________________________<br>> web-devel mailing list<br>> <a href="mailto:web-devel@haskell.org">web-devel@haskell.org</a><br>> <a href="http://www.haskell.org/mailman/listinfo/web-devel">http://www.haskell.org/mailman/listinfo/web-devel</a><br>
</div>