[Haskell-cafe] Top-down inserts in Persistent

[Michael Orlitzky]

On 12/30/2013 04:57 PM, Manuel Gómez wrote:
> On Mon, Dec 30, 2013 at 3:11 PM, Michael Orlitzky <michael at orlitzky.com> wrote:
>> On 12/29/2013 12:33 PM, Adam Bergmark wrote:
>> 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.
> 
> Are you sure a relational schema with the structure of each type of
> XML document is the best approach for your dataset?  It sounds like
> you could benefit from a less structured approach, since your data
> doesn’t sound very regular.

There's a complicated and uninteresting answer to this, so for now let's
just say the job is to get it into SQL somehow. I did consider other
options, but this is the path of least resistance, resistant as it may be.


> 
> Boris Lykah’s [Groundhog] library sounds like a good fit for your situation:
> 

I have been vacillating between Persistent and Groundhog in my
prototype. For now I'm using Groundhog, but I haven't written any code
yet that would rule out Persistent.


> <code>
> 
> This code will create a few tables: one for the `Driver` constructor,
> another for the `Car` constructor, and a couple of tables to keep
> track of what’s in the list in the `Driver` constructor.  It will even
> create triggers to help maintain the list-related tables clean,
> although I venture it’d be uncomfortable manipulating this specific
> generated schema by hand.

Yes! It is tempting isn't it? I emailed Boris about this and
unfortunately the list handling is unsupported (undocumented) and is
likely to disappear in its current form. Otherwise I had considered
running a manual migration after the Groundhog ones to create the
necessary views.


> Groundhog is very flexible with the sort of data types and schemas it
> can work with.  That example was getting a bit long so I didn’t
> include anything related to constraints, but specifying uniqueness
> constraints and the like is relatively painless.
> 
> Boris wrote a very nice [tutorial] for Groundhog in FP Complete’s
> School of Haskell, and the Hackage documentation for the
> [`groundhog-th`] package describes the `groundhog` quasiquoter pretty
> well.

Thank you for the suggestion; I do like the way Groundhog leaves my
types alone. If I can come up with a way to do a generic tree insert, it
will be necessary to leave out e.g. the "cars" column from the "people"
table (even though I still need it in the Haskell type).

At the moment I am banging my head against the Data.Data docs to try to
get that working. All I have so far is some writing on the wall in blood
about how Hackage 3 should automatically reject any function with more
than two type variables and no examples.