tony at tonybibbs.com
Tue Dec 14 09:53:05 EST 2004
Vincent Furia wrote:
>I now know more than I really ever wanted to about what Tony
>would like to see in a Hunting Log. :)
>Most everything looks to be on the up and up. I really liked how
>Propel and the MVCnPHP interact to make an application really easy to
>put together. I'm even starting to get used to the idea of having a
>central store to keep SQL queries (though it still seems a bit
>strange). We're going to need to expand it though to be able to
>handle different queries for different databases (hopefully a rare
>occurrence, but something I could easily see happening).
Yeah, good point. There are probably two ways to do this:
1) Each named_query file could be tied to specific database (read: dsn)
2) Modify the non-existent (but soon to be created) xml schema (i.e.
.xsd) to wrap the <query> tags in a <database> tag. Only issue there is
do we care to support queries that pull data across more than one
database? I vote for no...that's too complicated and I think in that
case you should just get a handle to the database connections you need
and go to work yourself. As much as I would like to keep our
commands/views free of SQL there will always be exceptions.
>Concerns: Creole. I'm sure its good, and everything I've read about
>it seems positive but it isn't in wide spread use and I have yet to
>see a performance benchmark with it compared to some of the other DB
>abstraction layers. The only reason I'm worried is that a slow
>abstraction layer can hamstring the speed of the entire program. This
>was seen a couple years ago when ADODB was 2-3x faster than PEAR::DB.
>I know a few projects that were using PEAR and suffered as a result (I
>understand that PEAR::DB has improved a lot since then, this was just
>Dislikes: I don't like using the DAO to abstract past the Propel
>classes. It seems silly and $dao->save($hunt) makes less sense to me
>than $hunt->save(). I understand you want to abstact in case we
>decide to replace Propel (or Creole, or something) some time in the
>distant future, but I think we could do that just as easily by
>changing the $hunt class, or inheriting it and overloading the
I'll tackle both of these at the same time. Using the DAO layer should
address your concerns about Creole both from a performance view and a
shelf-life perspective. It may seem like an un-needed layer of
abstraction but it builds just the sort of buffer we need so that if we
needed to make drastic changes to our data access layer that our
commands/views/etc wouldn't have to change much.
I can see your points on the using, for example, the save() method right
on the model object but I argue that this is actually a design flaw of
Propel as it breaks the rule of encapsulation. Domain objects, IMHO,
shouldn't need to know how to persist themselves to the database. The
persistence mechanism should be its own atomic bit of code and it should
know how to save any domain object.
I've sent a note to the propel-users list in hopes of having one of them
address the performance concerns. I'd like to think they have done some
benchmarking already...but you never know.
>And a note, I haven't actually looked at the code inside Propel or
>Creole. Unless someone (Tony) has taken a look, it might be a small
>risk that the code may be unmaintainable (though I doubt it). While
>Tony pointed out all this code is supported. If any of these projects
>one day die we may have to pick it up just to keep GL2 working... We
>really shouldn't depend on code that we would not be willing to
>maintain if push came to shove.
I've looked at some of the code. AFAICT, it's in pretty good shape with
a fairly good design. The model objects generate by Propel are actually
quite straightforward...the most complicated code is the lazy loading of
child objects for a given domain object and even that stuff isn't too
bad. But don't take my word for it...others should give it a gander and
tell me what they think. Oh, and I haven't looked at the Creole code at
More information about the geeklog-devel