Login | Register
My pages Projects Community openCollabNet

Reply to message

2020-03-13: This site is going to be decommissioned and shut down very soon. Please copy and archive any data you wish to keep ASAP

* = Required fields
* Subject
* Body
Send reply to
Author (directly in email)
Please type the letters in the image above.

Original message

Author Alan Pinstein <apinstein@mac.com>
Full name Alan Pinstein <apinstein@mac.com>
Date 2006-05-31 06:05:32 PDT
Message > That said, I think we do need a way for people to use custom SQL,
> because we're never going to account for all the crazy things people
> want to do.

Indeed... I like the idea of abstracted common functions, but some
situations *don't* call for DB-independence and require custom SQL.
We ONLY use postgres, and so we should be able to do postgres-only
things because for us there is no downside.

> Yeah, I'm less concerned about subqueries, since they're still only
> partially supported (AFAIK) in MySQL -- which definitely accounts
> for a
> large percentage of the userbase (I'm definitely curious just how
> large
> that percentage is). I certainly use subqueries, but at that point
> I'm
> just writing custom SQL, so I'm not worried about fitting it into
> Criteria.

One idea for the subquery might be to make a SubselectExpr which
contains a Query instance that can be used as a Criteria. That way
one would get the Propel benefits of identifier quoting, etc, but
still be able to do subqueries. This would provide subquery support
directly in propel without getting to complicated.