Re^2: RFC - A multi table SQL Builder

SQL::Abstract looks like it only does single-table queries. My module will build N-table queries where the tables are anywhere in your schema, so long as they are connected in some fashion.

Maybe my module is really an extension to SQL::Abstract?

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Comment on Re^2: RFC - A multi table SQL Builder

Replies are listed 'Best First'.
Re^3: RFC - A multi table SQL Builder by stvn (Monsignor) on Oct 17, 2004 at 23:47 UTC
Maybe my module is really an extension to SQL::Abstract? Maybe SQL::Abstract::Join? But I would only use that name is you truely were extending SQL::Abstract in some way to support joins. I think that SQL:: is a namespace which can be added too, but IMO SQL::Abstract:: should only be added to for things specific to or working with SQL::Abstract. Can we see more of the API? It looks like a very interesting module, I am curious how it works, etc in a larger example. And no, I dont know of anything like this on CPAN, then again, I either like to write my own SQL or use our in house OO Persistence tools. -stvn	[reply]
Re^3: RFC - A multi table SQL Builder by bart (Canon) on Oct 18, 2004 at 08:11 UTC
I love SQL::Abstract, in particular for `INSERT`, `UPDATE` and `DELETE`, but it's support for `SELECT` is IMO a bit limited. I see its disadvantages in (t least) these areas: `SELECT` is designed only for use for single tables, no support for any kind of `JOIN` No support for aggregated queries, using `GROUP BY` and `HAVING`. I'd love to see a module that supports these, but I wouldn't like to see Yet Another Incompatible Syntax. So yes, I vote for at least compatibility with SQL::Abstract, better yet, cooperation with it. That you might achieve by making your module an extension to it. But perhaps I'd like it best if you contacted the author/maintainer of SQL::Abstract, and together find a way to merge your respective modules, making your module actually part of SQL::Abstract. Co-authorship, so to speak.	[reply]