[Haskell-cafe] Top-down inserts in Persistent

[Michael Orlitzky]

On 12/29/2013 12:33 PM, Adam Bergmark wrote:
> Hi Michael,
> 
> The entity definitions in persistent is very close to the SQL schema, in
> a 1-to-many relation you must have the foreign key relation defined in
> the many table.
> 
> You should preferably not insert a car before it's owner is inserted,
> that would give you a null reference. So if possible you should insert
> people first which will return their id and you can then do the
> insertion of cars safely. You can also construct keys manually, this is
> kind of an hack since you may construct invalid IDs.
> 
> ...
> 
> Having some mismatch when moving things to relational storage is common.
> A lot of times I end up creating intermediary types that contain the
> data in a format that makes it easier to work with. But I don't mind
> this at all, Haskell makes it very safe to add proxy types and refactor
> them. You sometimes end up having to do more queries to the DB than
> seems necessary, but this is only a problem if it turns out to be a
> bottle neck.
> 

I have 650 XML documents -- all with different schemas -- to import.
Assuming some of them are outdated or unused, I might wind up doing 100
before I declare victory. Still an offensive amount of XML =)

To parse the XML I already need to create 100 Haskell data types; that
part is unavoidable. But since XML is XML, all of those data types are
trees.

Michael Snoyman suggested,

  forM_ people $ \(PersonXML name cars) -> do
    personId <- insert $ Person name
    forM_ cars $ \car -> insert_ $ Car personId car

which works for one tree, Person { [Car] }. But it doesn't work for
Person { [Car], [Shoes] }, or anything else. The essence of the problem
is that I don't want to write 100 functions like the forM above that all
do the same thing but to trees with slightly different shapes. They
should all follow the same pattern: insert the big thing, then insert
the little things with automatic foreign keys to the big thing.