| 1 |
Heya everyone, |
| 2 |
|
| 3 |
another (almost) week went by so here is another status report. |
| 4 |
|
| 5 |
As I stated in my last report one of key goals for this week was db |
| 6 |
layer for storing information retrieved by tinderboxes. I was looking |
| 7 |
into using various ORM frameworks. It was suggested to me to try Django |
| 8 |
and I though "Hey, that's not even ORM framework, but a web framework". |
| 9 |
|
| 10 |
Well one part of my project is creating web interface for database at |
| 11 |
later stage. So in spirit of not doing same thing twice I looked into |
| 12 |
using ORM part of Django. And guess what? I it doable, and basic |
| 13 |
implementation is in devel branch of my repo. |
| 14 |
|
| 15 |
There were certain caveats of course. Django is designed to work |
| 16 |
for web applications, not as general purpose ORM framework. So when |
| 17 |
using its ORM part without rest of Django, I have to take care of |
| 18 |
DB exceptions and rollback of transactions myself. I soon realized |
| 19 |
I am doing same thing in every db function I was writing so I ended |
| 20 |
up writing a decorator in Python (finally had a reason! :-) ). It |
| 21 |
looks something like this: |
| 22 |
|
| 23 |
--- CODE |
| 24 |
|
| 25 |
def dbquery(f): |
| 26 |
def decor(*args, **kwargs): |
| 27 |
reset_queries() |
| 28 |
try: |
| 29 |
return f(*args, **kwargs) |
| 30 |
except Exception, e: |
| 31 |
_rollback_on_exception() |
| 32 |
raise e |
| 33 |
return decor |
| 34 |
|
| 35 |
@dbquery |
| 36 |
def add_package(...) |
| 37 |
|
| 38 |
--- CODE |
| 39 |
|
| 40 |
This way we can be sure that failed transactions are rolled back. |
| 41 |
|
| 42 |
Because I am using Django to generate SQL now, orignal database |
| 43 |
schema that I commited to repository some time ago is now deprecated. We |
| 44 |
can generate database (and initial data) by using django-admin syncdb |
| 45 |
command now. |
| 46 |
|
| 47 |
This approach seems fairly good so far since everything was set-up by |
| 48 |
code that fits on one screen. I only wish using only small part of |
| 49 |
Django was less painful. |
| 50 |
|
| 51 |
|
| 52 |
And now comes the big part. Actually populating the database with some |
| 53 |
meaningful data. I did some work in that part. Last week there were some |
| 54 |
modifications to protocol I was using between Matchbox and Tinderboxes. |
| 55 |
Most of changes were touching code dealing with log/environment |
| 56 |
collection and fact that we have been compiling inside chroot |
| 57 |
environment. |
| 58 |
|
| 59 |
I also added support for packages that require certain use flags |
| 60 |
enabled/disabled for their dependencies. Good example is dev-utils/git |
| 61 |
(requires dev-utils/subversion[-dso]). For git this is however only |
| 62 |
RDEPEND (runtime dependency) so compilation doesn't depend on it. |
| 63 |
|
| 64 |
Since we already have db for storing results, and support is there let's |
| 65 |
compile some packages! For next week I plan to finally add proper |
| 66 |
testing to the mix. Instead of compiling fortune-mod over and over, |
| 67 |
Matchbox will ask also for other packages to be compiled. This will bring |
| 68 |
out some more problems that will need to be fixed I am sure. At least |
| 69 |
that's the idea... |
| 70 |
|
| 71 |
-- |
| 72 |
Stanislav Ochotnicky |
| 73 |
Working for Gentoo Linux http://www.gentoo.org |
| 74 |
Implementing Tree-wide collision checking and provided files database |
| 75 |
http://soc.gentooexperimental.org/projects/show/collision-database |
| 76 |
Blog: http://inputvalidation.blogspot.com/search/label/gsoc |
| 77 |
|
| 78 |
|
| 79 |
jabber: sochotnicky@×××××.com |
| 80 |
icq: 74274152 |
| 81 |
PGP: https://dl.getdropbox.com/u/165616/sochotnicky-key.asc |
Archives