Login | Register
My pages Projects Community openCollabNet

propel
Reply to message

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

Original message

Author Ants Aasma <ants.aasma@gmail.com>
Full name Ants Aasma <ants.aasma@gmail.com>
Date 2006-05-31 09:09:12 PDT
Message On 5/31/06, Alan Pinstein <apinstein at mac dot com> 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.

I'm not saying that custom SQL should be avoided. Just that there
should be an easy way of doing things the "right way". So those of us
who care about pretty design, can extend the criteria framework with
out custom expressions. Implement them only for the database that we
use, but leave the doors open for implementing them in a database
independent way.

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

That's pretty much what I had in mind. But there should be collection
specific criteria too like has more elements than, all elements equal
or any element is bigger than. These would do the joining and/or
subselecting for the user, making Propel easier to use than doing the
SQL yourself.

Any comments on the idea of providing more complex datatypes with Propel?

Ants Aasma