Conf cache
| Newsgroups | gmane.comp.lib.binarycloud.devel |
|---|---|
| Organization | Solutions Only |
| Message-ID | <4223505F.14168.1700424@localhost> |
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...
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 ?
Or is BC such that more than one workspace is not allowed?
Or should any workspace use a different database ?
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?
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).
Cheers,
wim niemans
_______________________________________________
dev mailing list
dev-PnctHDZWAvB/Cz2I37pSEPZ4XP/[email protected]
http://lists.binarycloud.com/mailman/listinfo/dev