Login | Register
My pages Projects Community openCollabNet

Reply to message

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

Original message

Author hlellelid
Full name Hans Lellelid
Date 2006-05-31 06:21:31 PDT
Message Alan Pinstein wrote:
>> 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.

Ok -- I think that we'll definitely have support for custom SQL one way
or another. I think abstracting some common functions (especially since
much of that work has already been done) is probably a good move.

>> 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.

Yeah, that would be pretty slick -- and shouldn't be too difficult.