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.