[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