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.
Re: SQL AST
Yes, I started looking at the perlmod related info and they suggested the email threads to talk about usefulness mainly, this is why I didn't worry about it not being able to run. That is basically another topic I wanted to talk about. My code depends on a thin layer that I created and that is the base of all my other libraries. This is a library with many (probably unrelated) smaller libraries that allow me to handle my own perl OOP implementation. That library can be found here: https://bitbucket.org/juankpro/model-support/src/master/ I was not sure, the best practices when you have this kind of dependencies that you're going to use for your next libraries, so that you don't have duplicated code, and so that it can be shared amongst them. 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.
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. pgpirp5FLG3im.pgp Description: Digitale Signatur von OpenPGP
