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 hlellelid
Full name Hans Lellelid
Date 2006-05-31 05:49:59 PDT
Message Hi -

Ants Aasma wrote:
> Hi,
> I looked at the examples you provided. The SqlExpr class seems a bit
> evil to me, as it leaks the database independence abstraction. I don't
> think it should be completely eliminated, but I do think its use
> should be heavily discouraged. Propel should provide a way to abstract
> the more frequently used expressions and provide a way to build plug
> in custom expressions so that the database dependent code goes into a
> well defined place. This will probably bring up the need for the
> criteria interface to be a bit more datatype aware.
> So the example
> $c = AuthorPeer::getCriteria();
> $c->add(new SqlExpr("char_length(name) = 4"));
> could be something like:
> $c->add(new EqualExpr(StringFiel​d::LengthExpr(Author​Peer::FIRST_NAME), 4));

Yeah, that's not a bad idea. I agree that we want to keep things
abstract. The SqlExpr class is a response to a relatively frequent
request to get custom SQL into Criteria.

Actually, some of this abstraction has already been done, as part of the
DBAdapter system -- e.g. there is a length() method, concat(), etc.
Maybe we just need to document & encourage that approach to query stuff.

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.

> By using this kind of SQL abstraction we could easily add commonly
> used abstract datatypes, such as timeperiod or money, and maybe even
> transparently support the Embedded Value (
> http://www.martinfow​ler.com/eaaCatalog/e​mbeddedValue.html ) pattern.
> This would shift propel a bit into the Data Mapper territory, but
> would make it a lot more suitable as a basis for a cleanly factored
> Domain Model.
> I still have to think a bit, how could we fit subqueries into the
> Criteria picture. It would be really sweet, if we could get something
> like this working:
> $c = HotelroomPeer::creat​eCriteria();
> $c->add( HotelroomPeer::RESER​VATIONS()->notAny​(
> ResevationPeer::TIME​PERIOD()->interse​cts( $conference->getTimeperiod()
> ) ) );
> $freeRooms = HotelroomPeer::doSelect( $c );

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.

What I don't want to do is create an extremely heavy & complex Criteria
to account for usage scenarios that we don't want to encourage anyway.
We want Criteria to make writing straightforward queries very easy (and
straightforward queries may have joins). When we start getting into
custom SQL expressions, subqueries, etc., we can provide a bit of
support, but really I think we want to encourage peopel to write SQL, as
that is where portability breaks down anyway.