Re: SQL AST

I also want to use the opportunity to clarify that this Arel impl is current with the latest version and contains all of the current features. At least as defined in the rails Arel impl. All additonal features around it are more related to ActiveRecord features constructed around it (that I might also implement as different modules in the future). I've also seen other Arel forks with different features but this is not the main Arel.


________________________________
From: Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯
Sent: Saturday, May 30, 2020 9:35 AM
To: module-authors@perl.org
Subject: Re: SQL AST

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.

• SQL AST by Juan Carlos Pazmiño
• Re: SQL AST by Juan Carlos Pazmiño
• Re: SQL AST by Juan Carlos Pazmiño
• Re: SQL AST by Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯