Re: [gentoo-portage-dev] [1/3] Cache subsystem rewrite

[Brian Harring]

On Fri, Nov 04, 2005 at 12:43:33AM +0900, Jason Stubbs wrote:
> On Monday 31 October 2005 02:14, Brian Harring wrote:
>
> +++ pym/cache/util.py	(revision 0)
> +	def exception(self, key, *arg):	print "exec",key,arg
>
> Should "exec" be "exec"?
print "key '%s' caught exception '%s'" % key, arg

> +++ pym/cache/mappings.py	(revision 0)
> +	def __init__(self, pull_items, initial_items=[]):
> ...
> +		self.pull = pull_items
> ...
> +			self.d.update(self.pull())
>
> What is pull_items? A function that returns a dict? If so, might be a good
> idea to name the parameter to something with "func" in it.

Or tag that info into the docstring, since the docstring is wrong 
quickly glancing at it...

> +++ pym/cache/metadata.py	(revision 0)
> +				for idx, c in enumerate(line):
idx=-1
for c in enumerate(line):
	idx += 1

will be substituted into the stable commit instead of enumerate...

> "enumerate" is a new one. Do you know which python version that was added in?
2.3

> +++ pym/cache/sql_template.py	(revision 0)
> +	SCHEMA_VALUES_CREATE	= "CREATE TABLE %s ( pkgid integer references %s
> (pkgid) on delete cascade, \
>
> There's plenty more, but this is a good enough example. You realize that MySQL
> won't be supported (until 5.1) ? Not saying that MySQL need be supported;
> just ensuring that you realize it.

Well aware... which is why it's broken out as (essentially) a global 
var.  If it were just a syntax issues, derivatives only have to modify 
the sql used.

If the underlying sql engine lacks a feature (triggers/refs), well, 
you modify the sql statements bound to the class so that it works.

The use of delete trigger and foreign key there is for ease of use for 
_all_ derivatives of the sql template- if a backend lacks capabilities 
that others have, well, they have to implement their own trickery (aim 
for maximal reuse for derivatives, with the odd balls having to do a 
bit more work).

Fex... for the bit above, would override SCHEMA_VALUES_CREATE to nuke 
the ref/trigger, then shift the delete sql into the class namespace, 
and have mysql override that.

> Haven't had a close look yet. It will probably all make more sense after
> looking at the second patch. You should probably commit the lot to subversion
> though. Tracing out bugs when they appear will speed up understanding
> greatly. ;)

/me cackles...
finally going to kill off the crap cache subsystem in place :)

I've been thinking about it for a while, only change I'm sitting on 
the fence about is how the tree path is stored in the backend; 
thinking of using the tree label instead.

With stable, moving your tree around is going to invalidate your 
cache... just how it goes.  If the code is shifted over to using 
labels internally for eclass storage, still is an issue, but only for 
stable- stable generates the label from the file path.

Under 3.0's config, user can label the tree/cache seperately, and move 
it around without this issue- course, changing the label of a tree 
will then result in invalidation...

Thoughts?
~harring