[debexpo-devel] Concept work nearly done
Jonny Lamb
jonnylamb at jonnylamb.com
Thu May 22 02:47:01 CEST 2008
Hi,
On Wed, May 21, 2008 at 05:44:11PM +0200, Christoph Haas wrote:
> Perhaps I'm missing it in the list. But is there a point where you intend
> to decide on the "Plugin API"? Perhaps it's way simpler than I imagine and
> just 10 lines of Python. I'd be curious though if there is a generic way
> to write plugins that work everywhere.
Yes, ticket #52! I can't believe you missed it! Okay, I just created it.
Thanks for the reminder!
The other tickets with "implement hook-support" titles just implement
actually calling the correct plugins according to the config file.
For example, ticket #10 has the title "Implement post-successful-upload
hook-support" (perhaps hook is a bad name). This one is implementing plugin
support for when the QA plugins should be run -- as in, just after an upload
has taken place. This ticket basically encapsulates reading the config
file at the correct point to know which plugins to run, importing the
plugin, and running it.
> Is Jabber widespread enough that it warrants an extra field here?
I don't know, but I've added it to the table anyway.
> There won't be more than one hash per user, right? What about putting that
> field into "users" then?
Hm, okay. 9/10 times that field will be empty, but it does simplify the
schema, so okay.
> How would this metric information get stored? I just see a "plugin" field
> here. I could imagine a whole list of personal preferences like
> programming languages (C, Perl, Python, Ruby, C++), helpers (debhelpers,
> CDBS), patch handlers (quilt, dpatch) etc. I know that many sponsors are
> pretty picky about the kind of software they sponsor. Might be great to
> take that information into account somehow.
Okay, so there's going to be loads of constant integers like
DE_METRIC_LANGUAGE (I totally haven't decided on the format and naming
of these yet -- it doesn't /really/ matter yet) and that'll go in the
attribute previously named "plugin" -- I'll change this name as I agree
the name is a little wrong. Then, there'll be a value constant like
DE_METRIC_LANGUAGE_PYTHON. This table specifically will be set in /my/
(the URL) by sponsors.
The actual implementation details for this aren't near being in stone
yet, but if the storage idea is fine, then great.
When all the plugins are run on the package, data will go into the
package_info table with package_info.from_plugin relating to
user_metrics.plugin (old name -- now you see why I called it plugin?)
and package_info.outcome relating to user_metrics.value.
Does this make sense..? I don't think I've explained it terrifically
well.
> Does PPA refer to the "personal package archive" software? I think I fail
> to understand what it's used for. To store source and binary package
> information? In that case I could imagine a table hierarchy like this:
>
> packages -> package_versions -> package_source -> package_files
> -> package_binary -> package_files
> -> package_comments
I was under the assumption that there were going to be two
repository-types in debexpo. One would be the main repository that
mentors.debian.net would use. The other (the PPAs) would be optional
and each user could have a personal repository. I assumed that the QA
checks, package commenting, etc. which is obviously very important in
the main repo (for mentors) would not take place in these PPAs. When I
think about it though, it seems a little flawed. Let me answer your next
question and conclude then...
> I'm confused. Could you explain the difference of "package_versions"
> versus "ppa_package_versions" for example? Usually the One-To-Many
> mappings of SQLAlchemy are pretty straightforward. You just have a foreign
> key from one table to another. Pseudocode:
[snip]
> The ORM notation of SQLAlchemy takes a little getting used to. But I find
> it pretty readable compared to the SQL mess it is under the hood. :)
Indeed, the foreign key from one table to another is pretty easy to set
up in SQlAlchemy, but I see a problem (hopefully I am not the only one
who sees it):
Okay, so say instead of ppa_packages we use packages. The package would
need to be identified whether it was from the normal repository uploaded
by a registered user, or uploaded into a user's PPA. I originally
thought that that was out of the question as one can't have an attribute
as double foreign key (right?), but I suppose thinking about it now,
there could be a user_id and a ppa_id key and allow only *one* of these
attributes used. How does this sound?
Okay, so looks like I overlooked a few things with the first revision of
the schema. I suppose that's a good thing, right?! This version's
changelog:
* Lose the ppa-specific package tables,
* Remove the verification table and add the field to users,
* Add jabber field to users,
* Change name of metrics "name" attribute.
Pretty diagram:
http://jdl.ducs.org.uk/misc/debexpo-db-2.png
Thoughts?
> Looks very nice. More routes will surely follow as soon as the coding
> frenzy begins. :)
Good.
Hopefully this clears up any confusion, and any problems.
Thanks,
--
Jonny Lamb, UK jonnylamb at jonnylamb.com
http://jonnylamb.com GPG: 0x2E039402
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://workaround.org/pipermail/debexpo-devel/attachments/20080522/3ec4ed0f/attachment.pgp
More information about the debexpo-devel
mailing list