headers
Tony Bibbs | 15 Apr 2009 22:24
Gravatar

DAO for Propel with Named Query support.

Ok, I've managed to get around to polishing off a DAO implementation
for Propel.  What makes this implementation unique is it adds a
powerful alternative to Criteria in what is dubbed Named Queries.
Named Queries are nothing more than XML files containing SQL queries
that are given names.  Those names can then be used to execute a
specific query.  Why, would anybody want this?

- It's a good middle ground between portability and the desire to
prevent having to learn a new way to write queries (e.g. Criteria or
something like HQL for you Hibernate fans).
- Allows a single SQL query to be reused in multiple parts of your application.
- It keeps your application clean by taking explicit SQL calls out of your code
- Allows for quick regression testing.  Because SQL is centralized
into one (or more) files you can easily write a unit test to
regression test all your queries after a database upgrade.
- Just like Criteria it returns Propel objects OR raw data.

How does it work?

- First, all Named Query files are validated against the included XSD
- XML is compiled into a PHP array for faster, subsequent access.
- Calls to a specific query cause the query to be pulled from the
array and then ran through a PDO prepared statement.

There are two parts to this implementation:

1) Generator (optional): we add a new PEER builder class that is DAO
aware.  The only thing this builder does special is it adds a
__callStatic() method (new to PHP 5.3) that knows how to call named
queries by name (example later).  To use it simply change set the
(Continue reading)

Permalink | Reply |
headers
Cameron Brunner | 15 Apr 2009 22:49
Picon

Re: DAO for Propel with Named Query support.

I've seen this mentioned a few times before and I don't think it would
be a 'bad' addition to propel but reading the existing code... there's
more than a couple things that need touching up (read: slow) and it
would need to hook into a caching module instead of having apc_*
hardcoded which means creating an interface for the caching module and
making a null/xcache/apc/memcache object to suit the interface as
well, probably some more things, it was only a quick glance at the
code. Personally I would rarely (probably never) use this as every
time I see this I think about the overhead this will create when you
get 1k+ queries in your xml file (too many people write bad code even
with the best help) but that's just me.

On Thu, Apr 16, 2009 at 6:24 AM, Tony Bibbs <tony <at> tonybibbs.com> wrote:
> Ok, I've managed to get around to polishing off a DAO implementation
> for Propel.  What makes this implementation unique is it adds a
> powerful alternative to Criteria in what is dubbed Named Queries.
> Named Queries are nothing more than XML files containing SQL queries
> that are given names.  Those names can then be used to execute a
> specific query.  Why, would anybody want this?
>
> - It's a good middle ground between portability and the desire to
> prevent having to learn a new way to write queries (e.g. Criteria or
> something like HQL for you Hibernate fans).
> - Allows a single SQL query to be reused in multiple parts of your application.
> - It keeps your application clean by taking explicit SQL calls out of your code
> - Allows for quick regression testing.  Because SQL is centralized
> into one (or more) files you can easily write a unit test to
> regression test all your queries after a database upgrade.
> - Just like Criteria it returns Propel objects OR raw data.
>
(Continue reading)

Permalink | Reply |
headers
Tony Bibbs | 15 Apr 2009 23:51
Gravatar

Re: DAO for Propel with Named Query support.

FWIW, you can have any number of XML files to address that concern.  
With the exception of VERY large apps I'd be surprised if you had  
anything approaching 1,000 queries because of the reuse you gain. Also  
because the XML is compiled into PHP you get the benefit of opcode  
caching. We're using this implementation on a number of production  
sites with no noticeable performance issues, though it would be worth  
running a few benchmarks against Criteria.

--Tony

On Apr 15, 2009, at 3:49 PM, Cameron Brunner  
<cameron.brunner <at> gmail.com> wrote:

> I've seen this mentioned a few times before and I don't think it would
> be a 'bad' addition to propel but reading the existing code... there's
> more than a couple things that need touching up (read: slow) and it
> would need to hook into a caching module instead of having apc_*
> hardcoded which means creating an interface for the caching module and
> making a null/xcache/apc/memcache object to suit the interface as
> well, probably some more things, it was only a quick glance at the
> code. Personally I would rarely (probably never) use this as every
> time I see this I think about the overhead this will create when you
> get 1k+ queries in your xml file (too many people write bad code even
> with the best help) but that's just me.
>
> On Thu, Apr 16, 2009 at 6:24 AM, Tony Bibbs <tony <at> tonybibbs.com>  
> wrote:
>> Ok, I've managed to get around to polishing off a DAO implementation
>> for Propel.  What makes this implementation unique is it adds a
>> powerful alternative to Criteria in what is dubbed Named Queries.
(Continue reading)

Permalink | Reply |
headers
Cameron Brunner | 16 Apr 2009 00:20
Picon

Re: DAO for Propel with Named Query support.

The first thing I noticed and the only reason I mentioned performance
is that you are doing multiple xpath queries in at least one of the
pieces of code where you could just as easily be doing one and doing
some more method calls instead, compared to Criteria it probably is
faster for a lot of things, it's just something I noticed (I don't
even know if it was in the code to generate the cache or what, I just
remember seeing it)

On Thu, Apr 16, 2009 at 7:51 AM, Tony Bibbs <tony <at> tonybibbs.com> wrote:
> FWIW, you can have any number of XML files to address that concern.
> With the exception of VERY large apps I'd be surprised if you had
> anything approaching 1,000 queries because of the reuse you gain. Also
> because the XML is compiled into PHP you get the benefit of opcode
> caching. We're using this implementation on a number of production
> sites with no noticeable performance issues, though it would be worth
> running a few benchmarks against Criteria.
>
> --Tony
>
>
>
> On Apr 15, 2009, at 3:49 PM, Cameron Brunner
> <cameron.brunner <at> gmail.com> wrote:
>
>> I've seen this mentioned a few times before and I don't think it would
>> be a 'bad' addition to propel but reading the existing code... there's
>> more than a couple things that need touching up (read: slow) and it
>> would need to hook into a caching module instead of having apc_*
>> hardcoded which means creating an interface for the caching module and
>> making a null/xcache/apc/memcache object to suit the interface as
(Continue reading)

Permalink | Reply |
headers
Tony Bibbs | 16 Apr 2009 04:03
Gravatar

Re: DAO for Propel with Named Query support.

Yeah, that code has room for improvement but keep in mind once the XML  
is compiled into PHP form we don't use xpath (or XML)...we just load  
the generated PHP file. We only go back to the XML file if you change  
it and, again, we simply recompile it to PHP.

On Apr 15, 2009, at 5:20 PM, Cameron Brunner  
<cameron.brunner <at> gmail.com> wrote:

> The first thing I noticed and the only reason I mentioned performance
> is that you are doing multiple xpath queries in at least one of the
> pieces of code where you could just as easily be doing one and doing
> some more method calls instead, compared to Criteria it probably is
> faster for a lot of things, it's just something I noticed (I don't
> even know if it was in the code to generate the cache or what, I just
> remember seeing it)
>
> On Thu, Apr 16, 2009 at 7:51 AM, Tony Bibbs <tony <at> tonybibbs.com>  
> wrote:
>> FWIW, you can have any number of XML files to address that concern.
>> With the exception of VERY large apps I'd be surprised if you had
>> anything approaching 1,000 queries because of the reuse you gain.  
>> Also
>> because the XML is compiled into PHP you get the benefit of opcode
>> caching. We're using this implementation on a number of production
>> sites with no noticeable performance issues, though it would be worth
>> running a few benchmarks against Criteria.
>>
>> --Tony
>>
>>
(Continue reading)

Permalink | Reply |

Gmane