Blog entries

Migration in Python Web Frameworks ORMs

2009/03/13 by Nicolas Chauvat

Today, I felt like doing a quick tour of the migration features provided by the ORMs used by the Python web frameworks. I started with Django. South looks better than Django-evolution which looks much better than dmigrations which is very low level. I also had a look at SQLAlchemy.migrate, but again, that's too low level for me since I am looking to define migrations with the same vocabulary that is used for the data model, independently of the underlying database schema.

http://south.aeracode.org/raw-attachment/wiki/Logo/logo-trac.png

The features listed in the South documentation have all been in CubicWeb for some time, except dependencies and autodetection. In my opinion, the dependency feature is not needed when you already have a list of scripts ordered by number, which is the case in South and in CubicWeb. The autodetection feature is more interesting, but it is tricky to get right. CubicWeb migration mechanism has had some kind of autodetection for a long time, but it is limited to the part that is easy to get right, yet quite common and useful:

  • synchronizing properties of attributes and relationships (i.e. a Person.name becomes fulltextindexed or a has_portfolio relationship changes from 1-1 to 1-n)
  • synchronizing permissions
http://farm2.static.flickr.com/1007/666142945_1d675bc2a7_m.jpg

For other common tasks like adding or removing entities and attributes, high-level directives are provided like add_entity_type or remove_attribute.

Up to now, not pushing autodetection of changes in the data model has been a deliberate choice, for diff'ing two models is complex and creating a migration path is even more difficult. Moreover, letting the ORM automatically overwrite local changes in the database schema can be harmful in some cases.

In CubicWeb, the idea is that the developer knows better than the framework, so let him decide what's best and provide him with a concise vocabulary to write the migration scripts.

photo by Tim in Sydney under creative commons.


Migrating cubicweb instances - benefits from a distributed architecture

2010/04/22 by Arthur Lutz

Aim : do the migration for N cubicweb instances hosted on a server to another with no downtime.

Prerequisites : have an explicit definition of the database host (not default or localhost). In our case, the database is hosted on another host. You are not migrating your pyro server. You are not using multisource (more documentation on that soon).

Steps :

  1. on new machine : install your environment (pseudocode)

    apt-get install cubicweb cubicweb-applications apache2
    
  2. on old machine : copy your cubicweb and apache configuration to the new machine

    scp /etc/cubicweb.d/ newmachine:/etc/cubicweb.d/
    scp /etc/apache2/sites-available/ newmachine:/etc/apache2/sites-available/
    
  3. on new machine : give new ids to pyro registration so the new instances can register

    cd /etc/cubicweb.d/ ; sed -i.bck 's/^pyro-instance-id=.*$/\02/' */all-in-one.conf
    
  4. on new machine : start your instances

    cubicweb start
    
  5. on new machine : enable sites and modules for apache and start it, test it using by modifying your /etc/host file.

  6. change dns entry from your oldmachine to newmachine

  7. shutdown your old machine (if it doesn't host other services or your database)

  8. That's it.

Possible enhancements : use right from the start a pound server behind your apache, that way you can add backends and smoothily migrate by shuting down backends that pound will take into account.

http://www.cubicweb.org/image/893561?vid=download

Building my photos web site with CubicWeb part II: security, testing and migration

2010/04/13 by Sylvain Thenault

This post will cover various topics:

  • configuring security
  • migrating an existing instance
  • writing some unit tests

Goal

Here are the read permissions I want:

  • folders, files, images and comments should have one of the following visibility rules:
    • 'public', everyone can see it
    • 'authenticated', only authenticated users can see it
    • 'restricted', only a subset of authenticated users can see it
  • managers (e.g. me) can see everything
  • only authenticated users can see people
  • everyone can see classifier entities (tag and zone)

Also, unless explicity specified, the visibility of an image should be the same as the visibility of its parent folder and the visibility of a comment should be the same as the one of the commented entity. If there is no parent entity, the default visibility is 'authenticated'.

Regarding write permissions, that's much easier:

  • the anonymous user can't write
  • authenticated users can only add comment
  • managers will add the remaining stuff

Now, let's implement that!

Proper security in CubicWeb is done at the schema level, so you don't have to bother with it in the views, for the users will only see what they have access to.

Step 1: adding permissions to the schema

In the schema, you can grant access according to groups or RQL expressions (users get access if the expression return some results). To implements the read security defined above, groups are not enough, we'll need to use RQL expressions. Here is the idea:

  • add a visibility attribute on folder, image and comment, with a vocabulary ('public', 'authenticated', 'restricted', 'parent')
  • add a may_be_read_by relation that links folder, image or comment to users,
  • add hooks to propagate permission changes.

So the first thing to do is to modify the schema.py of my cube to define these relations:

from yams.constraints import StaticVocabularyConstraint

class visibility(RelationDefinition):
    subject = ('Folder', 'File', 'Image', 'Comment')
    object = 'String'
    constraints = [StaticVocabularyConstraint(('public', 'authenticated',
                                               'restricted', 'parent'))]
    default = 'parent'
    cardinality = '11' # required

class may_be_read_by(RelationDefinition):
    subject = ('Folder', 'File', 'Image', 'Comment',)
    object = 'CWUser'

We can note the following points:

  • we've added a new visibility attribute to folder, file, image and comment using a RelationDefinition
  • cardinality = '11' means this attribute is required. This is usually hidden under the required argument given to the String constructor, but we can rely on this here (same thing for StaticVocabularyConstraint, which is usually hidden by the vocabulary argument)
  • the 'parent' possible value will be used for visibility propagation

Now, we should be able to define security rules in the schema, based on these new attribute and relation. Here is the code to add to schema.py:

from cubicweb.schema import ERQLExpression

VISIBILITY_PERMISSIONS = {
    'read':   ('managers',
               ERQLExpression('X visibility "public"'),
               ERQLExpression('X visibility "authenticated", U in_group G, G name "users"'),
               ERQLExpression('X may_be_read_by U')),
    'add':    ('managers',),
    'update': ('managers', 'owners',),
    'delete': ('managers', 'owners'),
    }
AUTH_ONLY_PERMISSIONS = {
        'read':   ('managers', 'users'),
        'add':    ('managers',),
        'update': ('managers', 'owners',),
        'delete': ('managers', 'owners'),
        }
CLASSIFIERS_PERMISSIONS = {
        'read':   ('managers', 'users', 'guests'),
        'add':    ('managers',),
        'update': ('managers', 'owners',),
        'delete': ('managers', 'owners'),
        }

from cubes.folder.schema import Folder
from cubes.file.schema import File, Image
from cubes.comment.schema import Comment
from cubes.person.schema import Person
from cubes.zone.schema import Zone
from cubes.tag.schema import Tag

Folder.__permissions__ = VISIBILITY_PERMISSIONS
File.__permissions__ = VISIBILITY_PERMISSIONS
Image.__permissions__ = VISIBILITY_PERMISSIONS
Comment.__permissions__ = VISIBILITY_PERMISSIONS.copy()
Comment.__permissions__['add'] = ('managers', 'users',)
Person.__permissions__ = AUTH_ONLY_PERMISSIONS
Zone.__permissions__ = CLASSIFIERS_PERMISSIONS
Tag.__permissions__ = CLASSIFIERS_PERMISSIONS

What's important in there:

  • VISIBILITY_PERMISSIONS provides read access to an entity:
    • if user is in the 'managers' group,
    • or if visibility attribute's value is 'public',
    • or if visibility attribute's value is 'authenticated' and user (designed by the 'U' variable in the expression) is in the 'users' group (all authenticated users are expected to be in this group)
    • or if user is linked to the entity (the 'X' variable) through the may_be_read_by permission
  • we modify permissions of the entity types we use by importing them and modifying their __permissions__ attribute
  • notice the .copy(): we only want to modify 'add' permission for Comment, not for all entity types using VISIBILITY_PERMISSIONS!
  • remaning parts of the security model is done using regular groups:
    • 'users' is the group to which all authenticated users will belong
    • 'guests' is the group of anonymous users

Step 2: security propagation in hooks

To fullfill our requirements, we have to implement:

Also, unless explicity specified, the visibility of an image should be the same as
the visibility of its parent folder and the visibility of a comment should be the same as the
one of the commented entity. If there is no parent entity, the default visibility is
'authenticated'.

This kind of 'active' rule will be done using CubicWeb's hook system. Hooks are triggered on database event such as addition of new entity or relation.

The tricky part of the requirement is in unless explicitly specified, notably because when the entity addition hook is executed, we don't know yet its 'parent' entity (eg folder of an image, image commented by a comment). To handle such things, CubicWeb provides Operation, which allow to schedule things to do at commit time.

In our case we will:

  • on entity creation, schedule an operation that will set default visibility
  • when a "parent" relation is added, propagate parent's visibility unless the child already has a visibility set

Here is the code in cube's hooks.py:

from cubicweb.selectors import implements
from cubicweb.server import hook

class SetVisibilityOp(hook.Operation):
    def precommit_event(self):
        for eid in self.session.transaction_data.pop('pending_visibility'):
            entity = self.session.entity_from_eid(eid)
            if entity.visibility == 'parent':
                entity.set_attributes(visibility=u'authenticated')

class SetVisibilityHook(hook.Hook):
    __regid__ = 'sytweb.setvisibility'
    __select__ = hook.Hook.__select__ & implements('Folder', 'File', 'Image', 'Comment')
    events = ('after_add_entity',)
    def __call__(self):
        hook.set_operation(self._cw, 'pending_visibility', self.entity.eid,
                           SetVisibilityOp)

class SetParentVisibilityHook(hook.Hook):
    __regid__ = 'sytweb.setparentvisibility'
    __select__ = hook.Hook.__select__ & hook.match_rtype('filed_under', 'comments')
    events = ('after_add_relation',)

    def __call__(self):
        parent = self._cw.entity_from_eid(self.eidto)
        child = self._cw.entity_from_eid(self.eidfrom)
        if child.visibility == 'parent':
            child.set_attributes(visibility=parent.visibility)

Remarks:

  • hooks are application objects, hence have selectors that should match entity or relation type to which the hook applies. To match relation type, we use the hook specific match_rtype selector.
  • usage of set_operation: instead of adding an operation for each added entity, set_operation allows to create a single one and to store the eids of the entities to be processed in the session transaction data. This is a good pratice to avoid heavy operations manipulation cost when creating a lot of entities in the same transaction.
  • the precommit_event method of the operation will be called at transaction's commit time.
  • in a hook, self._cw is the repository session, not a web request as usually in views
  • according to hook's event, you have access to different member on the hook instance. Here:
    • self.entity is the newly added entity on 'after_add_entity' events
    • self.eidfrom / self.eidto are the eid of the subject / object entity on 'after_add_relation' events (you may also get the relation type using self.rtype)

The 'parent' visibility value is used to tell "propagate using parent security" because we want that attribute to be required, so we can't use None value else we'll get an error before we get any chance to propagate...

Now, we also want to propagate the may_be_read_by relation. Fortunately, CubicWeb provides some base hook classes for such things, so we only have to add the following code to hooks.py:

# relations where the "parent" entity is the subject
S_RELS = set()
# relations where the "parent" entity is the object
O_RELS = set(('filed_under', 'comments',))

class AddEntitySecurityPropagationHook(hook.PropagateSubjectRelationHook):
    """propagate permissions when new entity are added"""
    __regid__ = 'sytweb.addentity_security_propagation'
    __select__ = (hook.PropagateSubjectRelationHook.__select__
                  & hook.match_rtype_sets(S_RELS, O_RELS))
    main_rtype = 'may_be_read_by'
    subject_relations = S_RELS
    object_relations = O_RELS

class AddPermissionSecurityPropagationHook(hook.PropagateSubjectRelationAddHook):
    __regid__ = 'sytweb.addperm_security_propagation'
    __select__ = (hook.PropagateSubjectRelationAddHook.__select__
                  & hook.match_rtype('may_be_read_by',))
    subject_relations = S_RELS
    object_relations = O_RELS

class DelPermissionSecurityPropagationHook(hook.PropagateSubjectRelationDelHook):
    __regid__ = 'sytweb.delperm_security_propagation'
    __select__ = (hook.PropagateSubjectRelationDelHook.__select__
                  & hook.match_rtype('may_be_read_by',))
    subject_relations = S_RELS
    object_relations = O_RELS
  • the AddEntitySecurityPropagationHook will propagate the relation when filed_under or comments relations are added
    • the S_RELS and O_RELS set as well as the match_rtype_sets selector are used here so that if my cube is used by another one, it'll be able to configure security propagation by simply adding relation to one of the two sets.
  • the two others will propagate permissions changes on parent entities to children entities

Step 3: testing our security

Security is tricky. Writing some tests for it is a very good idea. You should even write them first, as Test Driven Development recommends!

Here is a small test case that'll check the basis of our security model, in test/unittest_sytweb.py:

from cubicweb.devtools.testlib import CubicWebTC
from cubicweb import Binary

class SecurityTC(CubicWebTC):

    def test_visibility_propagation(self):
        # create a user for later security checks
        toto = self.create_user('toto')
        # init some data using the default manager connection
        req = self.request()
        folder = req.create_entity('Folder',
                                   name=u'restricted',
                                   visibility=u'restricted')
        photo1 = req.create_entity('Image',
                                   data_name=u'photo1.jpg',
                                   data=Binary('xxx'),
                                   filed_under=folder)
        self.commit()
        photo1.clear_all_caches() # good practice, avoid request cache effects
        # visibility propagation
        self.assertEquals(photo1.visibility, 'restricted')
        # unless explicitly specified
        photo2 = req.create_entity('Image',
                                   data_name=u'photo2.jpg',
                                   data=Binary('xxx'),
                                   visibility=u'public',
                                   filed_under=folder)
        self.commit()
        self.assertEquals(photo2.visibility, 'public')
        # test security
        self.login('toto')
        req = self.request()
        self.assertEquals(len(req.execute('Image X')), 1) # only the public one
        self.assertEquals(len(req.execute('Folder X')), 0) # restricted...
        # may_be_read_by propagation
        self.restore_connection()
        folder.set_relations(may_be_read_by=toto)
        self.commit()
        photo1.clear_all_caches()
        self.failUnless(photo1.may_be_read_by)
        # test security with permissions
        self.login('toto')
        req = self.request()
        self.assertEquals(len(req.execute('Image X')), 2) # now toto has access to photo2
        self.assertEquals(len(req.execute('Folder X')), 1) # and to restricted folder

if __name__ == '__main__':
    from logilab.common.testlib import unittest_main
    unittest_main()

It is not complete, but it shows most of the things you will want to do in tests: adding some content, creating users and connecting as them in the test, etc...

To run it type:

[syt@scorpius test]$ pytest unittest_sytweb.py
========================  unittest_sytweb.py  ========================
-> creating tables [....................]
-> inserting default user and default groups.
-> storing the schema in the database [....................]
-> database for instance data initialized.
.
----------------------------------------------------------------------
Ran 1 test in 22.547s

OK

The first execution is taking time, since it creates a sqlite database for the test instance. The second one will be much quicker:

[syt@scorpius test]$ pytest unittest_sytweb.py
========================  unittest_sytweb.py  ========================
.
----------------------------------------------------------------------
Ran 1 test in 2.662s

OK

If you do some changes in your schema, you'll have to force regeneration of that database. You do that by removing the tmpdb* files before running the test:

[syt@scorpius test]$ rm tmpdb*

BTW, pytest is a very convenient utilities to control test execution, from the logilab-common package.

Step 4: writing the migration script and migrating the instance

Prior to those changes, Iv'e created an instance, fed it with some data, so I don't want to create a new one, but to migrate the existing one. Let's see how to do that.

Migration commands should be put in the cube's migration directory, in a file named file:<X.Y.Z>_Any.py ('Any' being there mostly for historical reason).

Here I'll create a migration/0.2.0_Any.py file containing the following instructions:

add_relation_type('may_be_read_by')
add_relation_type('visibility')
sync_schema_props_perms()

Then I update the version number in cube's __pkginfo__.py to 0.2.0. And that's it! Those instructions will:

  • update the instance's schema by adding our two new relations and update the underlying database tables accordingly (the two first instructions)
  • update schema's permissions definition (the later instruction)

To migrate my instance I simply type:

[syt@scorpius ~]$ cubicweb-ctl upgrade sytweb

I will then be asked some questions to do the migration step by step. You should say YES when it asks if a backup of your database should be done, so you can get back to the initial state if anything goes wrong...

Conclusion

This is a somewhat long post that I bet you will have to read at least twice ;) There is a hell lot of information hidden in there... But that should start to give you an idea of CubicWeb's power...

See you next time for part III !


Building my photos web site with CubicWeb part IV: let's make it more user friendly

2010/07/13 by Sylvain Thenault

Step 0: updating code to CubicWeb 3.9 / cubicweb-file 1.9

CubicWeb 3.9 brings several improvements that we'll want to use, and the 1.9 version of the file cube has a major change: the Image type has been dropped in favor of an IImage adapter that makes code globally much cleaner (although this is not directly visible here). So the first thing to do is to upgrade our cube to the 3.9 API. As CubicWeb releases are mostly backward compatible, this is not mandatory but it's easier to follow changes as they come than having a huge upgrade to do at some point. Also, this remove deprecation warnings which are a bit tedious...

Since we only have very few lines of code, this step is pretty simple. Actually the main thing we have to do is to upgrade our schema, to remove occurrences of the Image type or replace them by the File type. Here is the (striped) diff:

 class comments(RelationDefinition):
     subject = 'Comment'
-    object = ('File', 'Image')
+    object = 'File'
     cardinality = '1*'
     composite = 'object'

 class tags(RelationDefinition):
     subject = 'Tag'
-    object = ('File', 'Image')
+    object = 'File'

 class displayed_on(RelationDefinition):
     subject = 'Person'
-    object = 'Image'
+    object = 'File'

 class situated_in(RelationDefinition):
-    subject = 'Image'
+    subject = 'File'
     object = 'Zone'

 class filed_under(RelationDefinition):
-    subject = ('File', 'Image')
+    subject = 'File'
     object = 'Folder'

 class visibility(RelationDefinition):
-    subject = ('Folder', 'File', 'Image', 'Comment')
+    subject = ('Folder', 'File', 'Comment')
     object = 'String'
     constraints = [StaticVocabularyConstraint(('public', 'authenticated',
                                                'restricted', 'parent'))]

 class may_be_readen_by(RelationDefinition):
-    subject = ('Folder', 'File', 'Image', 'Comment',)
+    subject = ('Folder', 'File', 'Comment',)
     object = 'CWUser'


-from cubes.file.schema import File, Image
+from cubes.file.schema import File

 File.__permissions__ = VISIBILITY_PERMISSIONS
-Image.__permissions__ = VISIBILITY_PERMISSIONS

Now, let's set the dependency in the __pkginfo__ file. As 3.8 simplifies this file, we can merge __depends_cubes__ (as introduced in the first blog of this series) with __depends__ to get the following result:

__depends__ = {'cubicweb': '>= 3.9.0',
               'cubicweb-file': '>= 1.9.0',
               'cubicweb-folder': None,
               'cubicweb-person': None,
               'cubicweb-zone': None,
               'cubicweb-comment': None,
               'cubicweb-tag': None,
               }

If your cube is packaged for debian, it's a good idea to update the debian/control file at the same time, so you won't forget it.

That's it for the API update, CubicWeb and cubicweb-file will handle other stuff for us. Easy, no?

We can now start some more fun stuff...

Step 1: let's improve site's usability for our visitors

The first thing I've noticed is that people to whom I send links to photos with some login/password authentication get lost, because they don't grasp they have to login by clicking on the 'authenticate' link. That's probably because they only get a 404 when trying to access an unauthorized folder, and the site doesn't make clear that 1. you're not authenticated, 2. you could get more content by authenticating yourself.

So, to improve this situation, I decided that I should:

  • make a login box appears for anonymous, so they see at a first glance a place to put the login / password information I provided
  • customize the 404 page, proposing to login to anonymous.

Here is the code, samples from my cube's views.py file:

from cubicweb.selectors import is_instance
from cubicweb.web import box
from cubicweb.web.views import basetemplates, error

class FourOhFour(error.FourOhFour):
    __select__ = error.FourOhFour.__select__ & anonymous_user()

    def call(self):
        self.w(u"<h1>%s</h1>" % self._cw._('this resource does not exist'))
        self.w(u"<p>%s</p>" % self._cw._('have you tried to login?'))

class LoginBox(box.BoxTemplate, basetemplates.LogFormView):
    """display a box containing links to all startup views"""
    __regid__ = 'sytweb.loginbox'
    __select__ = box.BoxTemplate.__select__ & anonymous_user()

    title = _('Authenticate yourself')
    order = 70

    def call(self, **kwargs):
        self.w(u'<div class="sideBoxTitle"><span>%s</span></div>' % self.title)
        self.w(u'<div class="sideBox"><div class="sideBoxBody">')
        self.login_form('loginBox')
        self.w(u'</div></div>')

The first class provides a new specific implementation of the default page you get on a 404 error, to display an explicit message for anonymous users.

Note

Thanks to the selection mechanism, it will be selected for anonymous users, since the additional anonymous_user() selector gives it a higher score than the default, and not for authenticated since this selector will return 0 otherwise (hence the object won't be selectable).

The second class defines a simple box, that will be displayed by default with boxes in the left column, thanks to default box.BoxTemplate'selector. The HTML is written to match default CubicWeb boxes style. To get the actual login form, we inherit from the LogFormView view which provides a login_form method (handling some stuff under the cover for us, hence the multiple inheritance), that we simply have to call to get the form's HTML.

login box / 404 screenshot

The login box and the custom 404 page for an anonymous visitor (translated in french)

Step 2: providing a custom index page

Another thing we can easily do to improve the site is... A nicer index page (e.g. the first page you get when accessing the web site)! The default one is quite intimidating (that should change in a near future). I will provide a much simpler index page that simply list available folders (e.g. photo albums in that site).

from cubicweb.web.views import startup

class IndexView(startup.IndexView):
    def call(self, **kwargs):
        self.w(u'<div>\n')
        if self._cw.cnx.anonymous_connection:
            self.w(u'<h4>%s</h4>\n' % self._cw._('Public Albums'))
        else:
            self.w(u'<h4>%s</h4>\n' % self._cw._('Albums for %s') % self._cw.user.login)
        self._cw.vreg['views'].select('tree', self._cw).render(w=self.w)
        self.w(u'</div>\n')

def registration_callback(vreg):
    vreg.register_all(globals().values(), __name__, (IndexView,))
    vreg.register_and_replace(IndexView, startup.IndexView)

As you can see, we override the default index view found in cubicweb.web.views.startup, getting back nothing but its identifier and selector since we override the top level view's call method.

Note

In that case, we want our index view to replace the existing one. We implement the registration_callback function, in which we code a registeration of everything in the module but our IndexView, then we register it instead of the former index view.

Also, we added a title that tries to make it more evident that the visitor is authenticated, or not. Hopefully people will get it now!

default index page screenshot

The default index page

new index page screenshot

Our simpler, less intimidating, index page (still translated in french)

Step 3: more navigation improvements

There are still a few problems I want to solve...

  • Images in a folder are displayed in a somewhat random order. I would like to have them ordered by file's name (which will usually, inside a given folder, also result ordering photo by their date and time)
  • When clicking a photo from an album view, you've to get back to the gallery view to go to the next photo. This is pretty annoying...
  • Also, when viewing an image, there is no clue about the folder to which this image belongs to.

I will first try to explain the ordering problem. By default, when accessing related entities by using the ORM's API, you should get them ordered according to the target's class fetch_order. If we take a look at the file cube's schema, we can see:

class File(AnyEntity):
    """customized class for File entities"""
    __regid__ = 'File'
    fetch_attrs, fetch_order = fetch_config(['data_name', 'title'])

By default, fetch_config will return a fetch_order method that will order on the first attribute in the list. We could expect to get files ordered by their name. But we don't. What's up doc ?

The problem is that files are related to folder using the filed_under relation. And that relation is ambiguous, eg it can lead to File entities, but also to Folder entities. In such a case, since both entity types don't share the attribute on which we want to sort, we'll get linked entities sorted on a common attribute (usually modification_date).

To fix this, we have to help the ORM. We'll do this in the method from the ITree folder's adapter, used in the folder's primary view to display the folder's content. Here's the code that I've put in our cube's entities.py file, since it's more logical stuff than view stuff:

from cubes.folder import entities as folder

class FolderITreeAdapter(folder.FolderITreeAdapter):

    def different_type_children(self, entities=True):
        rql = self.entity.cw_related_rql(self.tree_relation,
                                         self.parent_role, ('File',))
        rset = self._cw.execute(rql, {'x': self.entity.eid})
        if entities:
            return list(rset.entities())
        return rset

def registration_callback(vreg):
    vreg.register_and_replace(FolderITreeAdapter, folder.FolderITreeAdapter)

As you can see, we simply inherit from the adapter defined in the folder cube, then we override the different_type_children method to give a clue to the ORM's cw_related_rql method, that will generate the rql to get entities related to the folder by the filed_under relation (the value of the tree_relation attribute). The clue is that we only want to consider the File target entity type. By doing this, we remove the ambiguity and get back a RQL query that correctly orders files by their data_name attribute.

Note

  • Adapters have been introduced in CubicWeb 3.9 / cubicweb-folder 1.8.
  • As seen earlier, we want to replace the folder's ITree adapter by our implementation, hence the custom registration_callback method.

Ouf. That one was tricky...

Now the easier parts. Let's start by adding some links on the file's primary view to see the previous / next image in the same folder. CubicWeb provides a component that do exactly that. To make it appear, it has to be adaptable to the IPrevNext interface. Here is the related code sample, extracted from our cube's views.py file:

from cubicweb.selectors import is_instance
from cubicweb.web.views import navigation


class FileIPrevNextAdapter(navigation.IPrevNextAdapter):
    __select__ = is_instance('File')

    def previous_entity(self):
        rset = self._cw.execute('File F ORDERBY FDN DESC LIMIT 1 WHERE '
                                'X filed_under FOLDER, F filed_under FOLDER, '
                                'F data_name FDN, X data_name > FDN, X eid %(x)s',
                                {'x': self.entity.eid})
        if rset:
            return rset.get_entity(0, 0)

    def next_entity(self):
        rset = self._cw.execute('File F ORDERBY FDN ASC LIMIT 1 WHERE '
                                'X filed_under FOLDER, F filed_under FOLDER, '
                                'F data_name FDN, X data_name < FDN, X eid %(x)s',
                                {'x': self.entity.eid})
        if rset:
            return rset.get_entity(0, 0)

The IPrevNext interface implemented by the adapter simply consist of the previous_entity / next_entity methods, that should respectively return the previous / next entity or None. We make an RQL query to get files in the same folder, ordered similarly (eg by their data_name attribute). We set ascendant/descendant ordering and a strict comparison with current file's name (the "X" variable representing the current file).

Note

  • Former implements selector should be replaced by is_instance or adaptable selector with CubicWeb >= 3.9. In our case, is_instance is used to tell our adapter to get File entities.

Notice that this query supposes we wont have two files of the same name in the same folder. Fixing this is out of the scope of this blog. And as I would like to have at some point a smarter, context sensitive previous/next entity, I'll probably never fix this query (though if I had to, I would probably choose to add a constraint in the schema so that we can't add two files of the same name in a folder).

One more thing: by default, the component will be displayed below the content zone (the one with the white background). You can change this in the site's properties through the ui, but you can also change the default value in the code by modifying the context attribute of the component:

navigation.NextPrevNavigationComponent.context = 'navcontentbottom'

Note

context may be one of 'navtop', 'navbottom', 'navcontenttop' or 'navcontentbottom'; the first two being outside the main content zone, the two others inside it.

screenshot of the previous/next entity component

The previous/next entity component, at the bottom of the main content zone.

Now, the only remaining stuff in my todo list is to see the file's folder. I'll use the standard breadcrumb component to do so. Similarly as what we've seen before, this component is controlled by the IBreadCrumbs interface, so we'll have to provide a custom adapter for File entity, telling the a file's parent entity is its folder:

from cubicweb.web.views import ibreadcrumbs

class FileIBreadCrumbsAdapter(ibreadcrumbs.IBreadCrumbsAdapter):
    __select__ = is_instance('File')

    def parent_entity(self):
        if self.entity.filed_under:
            return self.entity.filed_under[0]

In this case, we simply use the attribute notation provided by the ORM to get the folder in which the current file (e.g. self.entity) is located.

Note

The IBreadCrumbs interface is a breadcrumbs method, but the default IBreadCrumbsAdapter provides a default implementation for it that will look at the value returned by its parent_entity method. It also provides a default implementation for this method for entities adapting to the ITree interface, but as our File doesn't, we've to provide a custom adapter.

screenshot of the breadcrumb component

The breadcrumb component when on a file entity, now displaying parent folder.

Step 4: preparing the release and migrating the instance

Now that greatly enhanced our cube, it's time to release it and to upgrade production site. I'll probably detail that process later, but I currently simply transfer the new code to the server running the web site.

However, there's some commands to get things done properly... First, as I've added some translatable string, I have to run:

$ cubicweb-ctl i18ncube sytweb

To update the cube's gettext catalogs (the '.po' files under the cube's i18n directory). Once the above command is executed, I'll then update translations.

To see if everything is ok on my test instance, I do:

$ cubicweb-ctl i18ninstance sytweb
$ cubicweb-ctl start -D sytweb

The first command compile i18n catalogs (e.g. generates '.mo' files) for my test instance. The second command starts it in debug mode, so I can open my browser and navigate through the web site to see if everything is ok...

Note

In the 'cubicweb-ctl i18ncube' command, sytweb refers to the cube, while in the two other, it refers to the instance (if you can't see the difference, reread CubicWeb's concept chapter !).

Once I've checked it's ok, I simply have to bump the version number in the __pkginfo__ module to trigger a migration once I'll have updated the code on the production site. I can check the migration is also going fine, by first restoring a dump from the production site, then upgrading my test instance.

To generate a dump from the production site:

$ cubicweb-ctl db-dump sytweb
pg_dump -Fc --username=syt --no-owner --file /home/syt/etc/cubicweb.d/sytweb/backup/tmpYIN0YI/system sytweb
-> backup file /home/syt/etc/cubicweb.d/sytweb/backup/sytweb-2010-07-13_10-22-40.tar.gz

I can now get back the dump file ('sytweb-2010-07-13_10-22-40.tar.gz') to my test machine (using scp for instance) to restore it and start migration:

$ cubicweb-ctl db-restore sytweb sytweb-2010-07-13_10-22-40.tar.gz
$ cubicweb-ctl upgrade sytweb

You'll have to answer some questions, as we've seen in an earlier post.

Now that everything is tested, I can transfer the new code to the production server, apt-get upgrade cubicweb 3.9 and its dependencies, and eventually upgrade the production instance.

Conclusion

This is a somewhat long post that starts showing you the way CubicWeb provides a highly configurable user interface, as well as powerful and reusable components. And there are a lot of others like those!

So see you next time for part V, where we'll probably want to do more ui stuff!