I know, i know, this is long overdue, but better late than never.
I have now lived in the flat for over a month, and so far i'm happy with it, i haven't found any problems yet. Painting took a little less than two weeks, with some added work for removing the tape from the windows (not the computer bug). You know, the tape you apply to the windows to avoid getting paint all over them, the problem is that if you are a bit on the slow side (say, like me), the tape will be stuck to the window for a few days. With the sun shining on them all day, we have had exceptionally good september weather here in Denmark, the glue on the tape then turns to super-glue, which takes several hours to remove, and a lot of rubbing. But i found a great way to get it off: just spray on some cleaning products and wait a few hours - comes right off.
No, this blog will not turn in to a DIY page.
I am now waiting for the furniture people to deliver my furniture, no time schedule on when that will happen, though.
On a completely different (although update related) note, i have converted the data backend to use PostgreSQL rather than my own HDF-hybrid, HDF is a simple data format used by the ClearSilver templating engine - the old design was not very multi-threading friendly, to say the least.
The new system uses SQLObject, a python library that enables database access just by declaring each table as a subclass of SQLObject and defining the fields, e.g. this is the definition of the wiki system on this page:
- class Wiki ( sqlobject.SQLObject ):
- name = sqlobject.StringCol ( alternateID = True, unique = True, length = 300, notNone = True )
- content = sqlobject.StringCol ( default = '', notNone = True )
- formatted = sqlobject.StringCol ( default = '', notNone = True )
- _defaultOrder = 'name'
Pretty, eh? I have also added some extra features to the wiki, like the notion of page hierachies (example) this is implemented by simply naming a subpage like: Konto/ChangeLog - not very advanced, but with an index on the name column of the Wiki table (see the alternateID parameter) it should be pretty efficient. Now, it is hard to imagine writing the "list subpages" query without writing some SQL code - but with SQLObject it is actually possibly - ok, we want the pages that begin with the name of a particular wiki page: '
- class Wiki ( sqlobject.SQLObject ):
- ...
- def listSubpages ( self ):
- return Wiki.select ( Wiki.q.name.startwith('%s/' % self.name) )
- ...
Well almost, this will give us all subpages, but if we only want immediate subpages, e.g. we want Konto/ChangeLog but not Konto/Some/OtherPage i have not been able to use SQLObject exclusively, so i had to employ some list-comprehension magic:
- class Wiki ( sqlobject.SQLObject ):
- ...
- def listSubpages ( self ):
- i = len ( self.name )
- return [w for w in Wiki.select ( Wiki.q.name.startswith('%s/' % self.name) ) if w.name[i+1:].find('/') == -1]
- ...
But still with this trick, it is important to note that i haven't written a single line of SQL, and it should work with any SQLObject backend (PostgreSQL, MySQL, SQLite, etc.).
I have also found a bit of time to work on the Glom relationship bounty, i now have the relationship arrows working, and you can move the tables around. Now i "just" need to find a great way to arrange the tables such that as few arrows as possible cross each other, preferably none. Hopefully i can dig up some graph theory on that from my library of books on the subject. There is a screenshot of my current progress at the top of this post.
I have a feeling that this might be a good reason for me to start reading the papers by the XVCG author, that tool is really impressive when it comes to automatically laying out graphs.
Oh and another thing, why is it so hard (impossible as far as i can tell) to find the bounties on the LaunchPad site? I had to use google to find it again. Do i sense a message from the authors?
Oh, and while developing this i found a "bug" in Glom - or maybe in the example project i am using, i use the Glom documnet model to query the relationships that i need to draw, but for some reason, one of the relationships are wrong, if you check the screenshot attached down here you can see that the Project Teams::team_id field points to Projects::projects_id field, this should rather be the Project Teams::project_id pointing to Projects::projects_id in my oppinion.
The screenshot is from a test version which draws arrows for both (from -> to) and (to -> from) relationships. I still need to get to the bottom of the problem before i have anything to report on the reasons for this.
On a not even closely related note, i have placed my first order on CafePress - this is a bit of a test order to see if they can deliver and if there are any "unknown" extra expenses imposed on the order.
I will write back as soon as i receive the order, promise! ;-)
Comments (2)
Very cool. Automatic layout would be nice, but it's not totally essential as long as we save the layout in the document.
Even if we start with a good arrangement, the user will still want to move things around to suit his way of picturing things. And he'll want that arrangement preserved.
Glad you like it.
I didn't even think of that, saving the location of the tables seems like a much better solution, although i haven't completely given up on trying to arrange them automatically - something a bit better than the current [HTML_REMOVED]on a single row[HTML_REMOVED].
Now i just need to figure out how to get the locations saved within the Glom document.
My gut feeling tells me i should examine Document_Glom in detail.
P.S. Just realized that by saving the locations, the examples could also have some default locations such that after you have created a project based on an example, the tables will be laid out in an [HTML_REMOVED]easy to get an overview[HTML_REMOVED] way.
Post comment
If you wish, you can use markdown syntax in the comment field.