Re: SQL AST

[email protected] (Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯) Sat, 30 May 2020 16:35:22 +0200 <[email protected]>

Newsgroups	perl.module-authors
Message-ID	<[email protected]>

I can't run the code, the dist has many undeclared/unpublished
dependencies. I would likely have more useful things to say about it if
I could run it.

> I need some feedback on wether you think it will be something that's
> useful.

Yes, but in a limited fashion: for people who require familiarity with
the Arel API or want to port code that uses Arel.

If I were to design an AST that aims to please everyone, I would give
it a plumbing and porcelain layer, both user accessible, and the
plumbing layer would map very closely to the parse tree, and the
porcelain would be a set of the features available in Arel, jooq,
sqlalchemy, linq etc.

> but all of them based on hash structures.

I agree that they are ripe for displacement. I have looked into this
topic before and found that DBIC is coupled quite tightly to
SQL::Abstract. If you want instant adoption from a large userbase, aim
to work so that DBIC can choose between SQL generators.

You have not picked a proper name yet. I think SQL::Arel is fine,
that's what the Pod name section already hints at.

signature.asc (application/pgp-signature, 833 B)