[web-devel] Data and Typeable

[Michael Snoyman]

On Fri, Apr 8, 2011 at 9:42 PM, Clint Moore <clint at ivy.io> wrote:

>
>
> On Thu, Apr 7, 2011 at 12:01 PM, Michael Snoyman <michael at snoyman.com>wrote:
>>
>> First, what's the 'right way' to get a string representation of a Key?
>>> I generate select form elements from subsets of data in a table.
>>>  Usually, resulting in 'select name="name_column" value="id_column"'
>>>
>>> I would probably use the Show instance, unless you have a compelling
>> reason not to.
>>
>
> Show on the key gives me 'TableId 1' instead of simply 1.  I'm assuming the
> expectation is not to split the table name off every time, though I don't
> see a function to get just the id of a row.  ie tableId
>
> > x <- myConnect $ selectList [TableNameNe "honk"] [] 0 0
> > fst $ head x
> TableId 1
>
> > tableId $ snd x  <- convenient!
>
>
I think the function you're looking for is fromPersistKey, which will give
you back an Int64. Be warned, however, that in Persistent 0.5, it will
instead give you back a PersistValue, since some backends (MongoDB in
particular) use more than 64 bits for their keys.


>
> Second, for types that have relationships, is there a shortcut or something
>>> I'm not seeing that will allow me to derive Data and Typeable?
>>> example:
>>>
>>> Species
>>>  name String Eq
>>>  deriving Data Typeable
>>>
>>> Animal
>>>  name String
>>>  species SpeciesId
>>>  deriving Data Typeable  <-- error!  There aren't instances generated, at
>>> least that it can find, of SpeciesId for Data.Data
>>>
>>> I wanted to enable this by default in Persistent, but it would require
>> user code to have DeriveDataTypeable enabled. I can consider putting it back
>> in, but I wouldn't mind web-devels input.
>>
>
> For my uses, the only place that this makes life much easier is when using
> HStringTemplate.  If it were enabled, you could simply set a row as an
> argument directly with 'setAttribute' instead of having to massage the data
> beforehand.
>
> Other than that, I can't think of a compelling reason to enable it by
> default.
>
> As I write this, I thought perhaps you could add cabal flags to enable this
> if you knew that you needed it, but then you start having to litter your
> code with #ifdefs and that starts to make code look very ugly very quickly.
>
> Maybe someone has another compelling use case for enabling this by default?
>
>
>

I definitely don't want to deal with cabal flags for this, it would mean
that some packages wouldn't install on your system depending on how you
build Persistent. For your case, it might be acceptable to just use
standalone deriving declarations, ie:

deriving instance Data SpeciesId
deriving instance Data Animal
...

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20110409/10f9d8cb/attachment.htm>