« Return to Thread: Caching of describeTable
Re: Caching of describeTable
by Christopher Thompson-2
::
Rate this Message:
I think at the lowest layer of this system, the schema details are in
the code no matter what you do. And I think it is probably the simplest
in many cases to define the schema in code because that definition is
adjacent to the code using it. Let's be honest -- syncing schema and
code is pretty trivial for a large number of PHP projects (80/20) and it
is done in code most of the time.
Automating keeping the code in sync with the actual schema really should
be an optional wrapper or plugin to the core db code. Whether the schema
data is hand updated, comes from DESCRIBE or TTL or is code generated by
a tool is a decision that is up to the programmer. DESCRIBE, TTL and
generated code all need a well defined target to which the data is
applied -- and that should be a clear manual configuration system in the
core code.
If the code can be wrapped in automation layers then ZF can provide
those that Zend feel are both most suitable and best practices, but it
enables others to build wrappers as they see fit.
Bill Karwin wrote:
> It's true that requiring a describe() on every page request is costly.
> I've seen reports that performance is poor for describe and other usage
> of the INFORMATION_SCHEMA virtual tables, in MySQL. Not surprising that
> the feature was not designed for high performance, under the assumption
> that will be queried infrequently.
>
> Caching the metadata automagically is one solution. TTL is probably of
> the least expensive way to get some benefit out of the cache, but allow
> for changes to occur without requiring manual intervention to update the
> app's view of the metadata. There should also be some method to purge
> the cache before the TTL expires. I'd hate to be that developer telling
> the Marketing VP that we've changed the schema, but the app won't notice
> the change for another two hours!
>
> One should be able to tune the TTL down to zero or near zero during
> development. Schema changes are much more frequent during development,
> and making the TTL tunable would be the most transparent way to handle
> this.
>
> I don't think putting schema details into the code is the best
> solution. This would be equivalent to putting a schema description into
> a config file, which is one thing we're committed to avoiding in Zend
> Framework. With that solution, it is difficult to keep the schema
> description in sync with the actual schema. Letting the Db component
> refresh this for you and cache the results for you would be a better
> solution.
>
> Bill
>
> Andi Gutmans wrote:
>> I think there are a few options here which we discussed in the past:
>> a) Use Zend_Cache to cache the info with a TTL.
>> b) Implement a very lightweight Zend_Db specific cache with TTL.
>> c) Auto-generate classes (i.e. manual update). Theoretically that and
>> Cache
>> are similar solutions as Cache can also be manually generated.
>>
>> Anyway, Bill is working right now to come with a suggestion for what the
>> scope of Zend_Db is and if we need an additional layer, what that
>> would be.
>> This issue will definitely be taken into account.
>>
>> Thanks.
>>
>> Andi
>>
>>
>>> -----Original Message-----
>>> From: Shahar Evron [mailto:shahar.e@...] Sent: Monday, January
>>> 01, 2007 6:15 AM
>>> To: fw-db@...
>>> Subject: [fw-db] Caching of describeTable
>>>
>>> Hi,
>>>
>>> Maybe I just need to RTFM but this one is a quickie: Is there a
>>> caching solution for Zend_Db_Adapter_xxx::describeTable() ?
>>>
>>> That one gets called quite frequently, and is very unlikely to change
>>> in production environemtns. Caching it somehow would be a smart idea.
>>>
>>> If nobody has suggestions, I'll do some hacking later and post an
>>> article about it.
>>>
>>> TIA,
>>>
>>> Shahar.
>>>
>>>
>>
>>
>>
>
>
>
the code no matter what you do. And I think it is probably the simplest
in many cases to define the schema in code because that definition is
adjacent to the code using it. Let's be honest -- syncing schema and
code is pretty trivial for a large number of PHP projects (80/20) and it
is done in code most of the time.
Automating keeping the code in sync with the actual schema really should
be an optional wrapper or plugin to the core db code. Whether the schema
data is hand updated, comes from DESCRIBE or TTL or is code generated by
a tool is a decision that is up to the programmer. DESCRIBE, TTL and
generated code all need a well defined target to which the data is
applied -- and that should be a clear manual configuration system in the
core code.
If the code can be wrapped in automation layers then ZF can provide
those that Zend feel are both most suitable and best practices, but it
enables others to build wrappers as they see fit.
Bill Karwin wrote:
> It's true that requiring a describe() on every page request is costly.
> I've seen reports that performance is poor for describe and other usage
> of the INFORMATION_SCHEMA virtual tables, in MySQL. Not surprising that
> the feature was not designed for high performance, under the assumption
> that will be queried infrequently.
>
> Caching the metadata automagically is one solution. TTL is probably of
> the least expensive way to get some benefit out of the cache, but allow
> for changes to occur without requiring manual intervention to update the
> app's view of the metadata. There should also be some method to purge
> the cache before the TTL expires. I'd hate to be that developer telling
> the Marketing VP that we've changed the schema, but the app won't notice
> the change for another two hours!
>
> One should be able to tune the TTL down to zero or near zero during
> development. Schema changes are much more frequent during development,
> and making the TTL tunable would be the most transparent way to handle
> this.
>
> I don't think putting schema details into the code is the best
> solution. This would be equivalent to putting a schema description into
> a config file, which is one thing we're committed to avoiding in Zend
> Framework. With that solution, it is difficult to keep the schema
> description in sync with the actual schema. Letting the Db component
> refresh this for you and cache the results for you would be a better
> solution.
>
> Bill
>
> Andi Gutmans wrote:
>> I think there are a few options here which we discussed in the past:
>> a) Use Zend_Cache to cache the info with a TTL.
>> b) Implement a very lightweight Zend_Db specific cache with TTL.
>> c) Auto-generate classes (i.e. manual update). Theoretically that and
>> Cache
>> are similar solutions as Cache can also be manually generated.
>>
>> Anyway, Bill is working right now to come with a suggestion for what the
>> scope of Zend_Db is and if we need an additional layer, what that
>> would be.
>> This issue will definitely be taken into account.
>>
>> Thanks.
>>
>> Andi
>>
>>
>>> -----Original Message-----
>>> From: Shahar Evron [mailto:shahar.e@...] Sent: Monday, January
>>> 01, 2007 6:15 AM
>>> To: fw-db@...
>>> Subject: [fw-db] Caching of describeTable
>>>
>>> Hi,
>>>
>>> Maybe I just need to RTFM but this one is a quickie: Is there a
>>> caching solution for Zend_Db_Adapter_xxx::describeTable() ?
>>>
>>> That one gets called quite frequently, and is very unlikely to change
>>> in production environemtns. Caching it somehow would be a smart idea.
>>>
>>> If nobody has suggestions, I'll do some hacking later and post an
>>> article about it.
>>>
>>> TIA,
>>>
>>> Shahar.
>>>
>>>
>>
>>
>>
>
>
>
« Return to Thread: Caching of describeTable
| Free embeddable forum powered by Nabble | Forum Help |
