[debexpo-devel] Concept work nearly done
Christoph Haas
email at christoph-haas.de
Wed May 21 17:44:11 CEST 2008
Hi, Jonny...
thanks for filling the Trac and sending out the initial timeline and
database schema.
On Mittwoch, 21. Mai 2008, Jonny Lamb wrote:
> Ticket creation
> ===============
>
> I have been doing a bit of debexpo research recently and have been
> filing tickets in the tracker[0] to track each milestone.
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.
> Database
> ========
>
> I also have designed the database schema and it can be viewed here:
>
> http://jdl.ducs.org.uk/misc/debexpo-db.png
>
> Please tell me if you see anything missing though. I wouldn't be
> surprised if I've completely forgotten about something! A quick run-down
> of the tables, in no order:
>
> - users -- registered users on the system
Is Jabber widespread enough that it warrants an extra field here?
> - user_verification -- a string that is used in verifying a user. If a
> user has verification string here, the user is not active.
There won't be more than one hash per user, right? What about putting that
field into "users" then?
> - user_countries -- list of valid countries
> - package_info -- "info" on a package version. This will contain output
> from plugins like Lintian.
> - package_versions -- this is so there can be multiple versions of a
> package uploaded at once, and so the package keeps a history of
> uploads.
> - packages -- simply package in the repository
> - package_version_files -- files (diff.gz,dsc,orig.tar.*) in a package
> version.
> - package_comments -- comments that other users give to packages.
> - user_metrics -- user package preferences (e.g. prefers CDBS over
> straight dh)
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.
> - ppa -- this is basically somewhere to store a name for a PPA as I
> think using a user's email address in the URL is a little sick. This
> could go into the users table I suppose, but that would mean having
> a redundant column when PPAs are disabled, and this way allows PPAs
> to be more pluginable.
> - ppa_packages -- contains source package information
> - ppa_package_versions -- contains version information for a package in
> the PPA. This way there can be multiple versions in the PPA
> - ppa_package_binaries -- information about binary packages
> - ppa_package_sources -- information about source packages
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
> Some notes:
>
> * I would have liked the PPA functionality re-use some of the
> package_* tables (I.e. instead of ppa_package_versions, using
> package_versions), but unfortunately, as far as I understand, I
> won't be able to use SQLAlchemy's nice relational features (E.g.
> [0]). Please correct me if I am wrong.
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:
kpdf = model.query(Package).filter_by(name='kpdf') # refers to "packages"
print kpdf
-> Package(kpdf)
print kpdf.versions # refers to "package_versions" / one-to-many
-> Version(kpdf, 1.0), Version(kpdf, 1.1)
print kpdf.versions[0].source_packages # refers to package_source
-> SourcePackage(kpdf-1.0-1), SourcePackage(kpdf-1.0-2)
print kpdf.versions[0].source_packages[0].files
-> File(kpdf-1.0-1_i386.changes),
File(kpdf-1.0.orig.tar.gz),
File(kpdf-1.0-1.dsc)
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. :)
> Routes
> ======
>
> Additionally I have set out a list of most URLs required. Feedback
> appreciated on whether these are nice enough names, and of course,
> whether the URL scheme I'm thinking of is sane:
>
> / welcome page
> /my/ account modification
> /my/packages/ my packages currently uploaded
> /register/ register new user
> /packages/ list of packages
> /packages/maintainer/ list of maintainers
> /packages/maintainer/user at user.com/ show packages of user
> /packages/section/ browse sections
> /packages/section/python/ show packages in "python"
> /packages/potential/ sponsor's potentially ideal packages to upload
> /package/packagename/ show packagename info
> /rss/package/packagename/ RSS feed of updates to a package
> /rss/packages/maintainer/... RSS feed for specific maintainer
> /rss/packages/section/... RSS feed for specific section
> /search/ search the site
Looks very nice. More routes will surely follow as soon as the coding
frenzy begins. :)
Cheers
Christoph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://workaround.org/pipermail/debexpo-devel/attachments/20080521/de53dc81/attachment.pgp
More information about the debexpo-devel
mailing list