On Fri, Apr 8, 2011 at 9:42 PM, Clint Moore wrote:

On Thu, Apr 7, 2011 at 12:01 PM, Michael Snoyman 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