Re: Conf cache

[email protected] schrieb:
> Hi all,
> 
> This is an obvious one, I guess. But I need to ask.
> 
> 
>>The workspace wide configuration files are in ${build_dir}/conf.
>>In a phingless binarycloud, the workspace root will be directly
>>served so it is $WORKSPACE/conf there.
> 
> 
> I assume that the ConfCache can be written into this directory.
> It is thus a cache per workspace. Right? Read more...

 From http://www.binarycloud.com/index.php/Drafts/NewConfigurationDraft

 > Additionally, Conf will provide caching facilities. The cache will be
 > written to a directory conf below the workspace’s cache directory. We
 > have to evaluate whether serializing or a var_export()/value_dump()
 > yields data that is faster to load.

We have a cache directory in a built workspace: $BUILT/tmp/cache.

> The source  for Conf comes either from files, either from the database, 
> either a combination. Forget the combination for now, and let's focus on 
> the files and database separately.
> 
> When Conf uses files, it be xml or php, a fileset can be defined for the 
> factory-level and a fileset can be defined for the workspace-level.
> 
> When Conf uses a database, a separate table can be defined for the factory-
> level and a separate table can be defined for the workspace-level.
> 
> I see no use for a level_flag since a workspace has a name and we must 
> distinguish between workspaces in the database. Correct ?

Above you propose to have one for factory defaults and another for other 
settings - it would be more elegant to have levels - eh?

> Or is BC such that more than one workspace is not allowed?
 > Or should any workspace use a different database ?

We agreed on IRC that we want one configuration database for each built 
workspace.

> The alternative would be to prepend the path with workspace name.
> Any voters yet?
> 
> Now. the caching. Assume that caching is running ok.
> This could be made intelligent, caching all on the fly.
> Somebody changes some conf_values and wants to flush the cache.
> So the caching starts freshly.
> 
> The point now is, what should be flushed? I mean, which cache?

I think we talked that over some ten mails before. I proposed Smarty 
like caching parameters and Jcm proposed simply "no cache" and "cache" 
for development/production.

> Possible solutions:
> 1. flush them all.
> 2. flush specific by handed parameter.
> 3. have conf cache in a central place, independent from workspace.
> 4. have the flushing in an adminscreen (to be designed).

Trivial, simply call Conf::flushCache() and add a simple button on a page.


Manuel
_______________________________________________
dev mailing list
dev-PnctHDZWAvB/Cz2I37pSEPZ4XP/[email protected]
http://lists.binarycloud.com/mailman/listinfo/dev