3

I do not want an ORM. I am comfortable with writing heavily targeted and optimized queries on my own, and I do not want any sort of ORM bloating my code.

I am looking for a light-weight, object-oriented query parser and builder that can transform an existing SQL string into a malleable query building object for further manipulation before recompiling and executing on the database.

The use case itself is updating queries that execute against tables within a public schema that contain current-valid information with substitute tables from an auditing schema while adding predicates in the WHERE clause to present point-in-time data from the (newly substituted) valid-time state tables.

My other use case is to manipulate pre-written queries to provide additional filters before execution.

A parser / builder will allow me to write current-valid queries but transform them effortlessly into the point-in-time equivalent. I'm currently planning on raiding Doctrine 2's QueryBuilder for the reconstruction part. Does anyone know of a an excellent library for parsing SQL queries into their base components?

j0k
  • 22,600
  • 28
  • 79
  • 90
Kenaniah
  • 5,171
  • 24
  • 27
  • 6
    I thought I was reading a science fiction novel for a few moments there. – Dan Grossman Feb 24 '11 at 18:35
  • Just a note: the intention of an ORM is not to spare you the work of dealing in SQL so much as it is to provide an adapter to assist your object-based application in working with relational datasets in a sane, clear way. It's often a lot of additional work to use one, but it can save your ass in terms of avoiding bugs and remaining agile, especially when it supports different databases and engines without additional work on your part. – coreyward Feb 24 '11 at 18:59
  • Coreyward, nothing wrong with that. Thing is, abstraction is useless, as the app is targeted for PostgreSQL (which I'm quite happy about). My app doesn't need relational code when I'm dealing with an RDBMS. The vast majority of that logic is left up to the DB. I just need to be responsible about writing well-formed transactions, which isn't rocket science by any stretch of the imagination. In short, there's not much value in using an ORM. I actually work much faster without one (not to mention there's less stuff to debug). Sadly, I don't have the space to rant about performance... – Kenaniah Feb 24 '11 at 19:13
  • There is a good chance that there is a perl CPAN module you could port to PHP, if someone has not already done so. – Roger Halliburton Feb 24 '11 at 20:27

1 Answers1

0

This one looked pretty good (I have not used it), but it is not PHP -- you could run the Java one server side by invoking from PHP using exec() and possibly work it into your script

http://www.sqlparser.com/

Johnathan Hebert
  • 661
  • 5
  • 8