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.
