[F] views: fix 2 unicode errors
1. You can now use valid unicode strings in ValidationError exception.
Previously, if 'err' contains unicode, UnicodeDecodeError was raised by format_errors()
>>> templstr = '<li>%s</li>\n'
>>> e = ValidationError(None, {None: u'oué, une exception en unicode!'})
>>> templstr % e
'<li>None (None): ou\xc3\xa9, une exception en unicode!</li>\n'
>>> templstr = u'<li>%s</li>\n'
>>> templstr % e
u'<li>None (None): ou\xe9, une exception en unicode!</li>\n'
2. The message of an Exception can contains unicode. But it now properly managed by “informal” string representation.
We can easily fix the problem by using the Exception.message attribute that still contains the original message.
>>> a = AssertionError(u'séfdsdf')
>>> a.message
u's\xe9fdsdf'
>>> str(a)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 1: ordinal not in range(128)
>>> a = ValueError(u'fsdfsdéfsdfs')
>>> str(a)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 6: ordinal not in range(128)
>>> a
ValueError(u'fsdfsd\xe9fsdfs',)
>>> unicode(a)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 6: ordinal not in range(128)
>>> a.message
u'fsdfsd\xe9fsdfs'
Migration
=========
Une des ides de base d'CubicWeb est la cration incrmentale d'application, et
pour cela de nombreuses actions sont fournies afin de facilement faire voluer
une application et tout particulirement le modle de donnes manipul sans
perdre les donnes des instances existantes.
La version courante d'un modle d'application est donnes dans le fichier
`__pkginfo__.py` sous forme d'un tuple de 3 entiers.
Gestion des scripts de migrations
---------------------------------
Les scripts des migrations doivent tre placs dans le rpertoire `migration` de
l'application, et nomm de la manire suivante :
<n de version X.Y.Z>[_<description>]_<mode>.py
dans lequel :
* X.Y.Z correspond au n de version du modle vers lequel le script permet de
migrer,
* le *mode* (entre le dernier "_" et l'extension ".py") indique quelle partie
de l'application (serveur RQL, serveur web) le script s'applique en cas
d'installation distribue. Il peut valoir :
* `common`, s'applique aussi bien sur le serveur RQL que sur le serveur web,
et met jour des fichiers sur le disque (migration de fichier de
configuration par exemple).
* `web`, s'applique uniquement sur le serveur web, et met jour des fichiers
sur le disque
* `repository`, s'applique uniquement sur le serveur RQL, et met jour des
fichiers sur le disque
* `Any`, s'applique uniquement sur le serveur RQL, et met jour des
donnes en base (migrations de schma et de donnes par ex.)
Toujours dans le rpertoire `migration`, le fichier spcial `depends.map` permet
d'indiquer que pour migrer vers une version spcifique du modle, il faut tout
d'abord avoir migrer vers une version donnes de cubicweb. Ce fichier peut contenir
des commentaires (lignes commenant par un "#"), et une dpendance est note sur
une ligne de la manire suivante : ::
<n de version du modle X.Y.Z> : <n de version cubicweb X.Y.Z>
Par exemple ::
0.12.0: 2.26.0
0.13.0: 2.27.0
# 0.14 works with 2.27 <= cubicweb <= 2.28 at least
0.15.0: 2.28.0
Contexte de base
----------------
Les identifiants suivants sont prffinis dans les scripts de migration :
* `config`, configuration de l'instance
* `interactive_mode`, boolen indiquant si le script est xcut en mode
interactif ou non
* `appltemplversion`, version du modle d'application de l'instance
* `applcubicwebversion`, version cubicweb de l'instance
* `templversion`, version du modle d'application installe
* `cubicwebversion`, version cubicweb installe
* `confirm(question)`, fonction posant une question et retournant vrai si
l'utilisateur a rpondu oui, faux sinon (retourne toujours vrai en mode non
interactif)
* `_`, fonction quivalente `unicode` permettant de marquer des chaines
internationaliser dans les scripts de migration
Dans les scripts "repository", les identifiants suivant sont galement dfinis :
* `checkpoint`, demande confirmant et effectue un "commit" au point d'appel
* `repo_schema`, schma persistent de l'instance (i.e. schma de l'instance en
cours de migration)
* `newschema`, schma install sur le systme de fichier (i.e. schma de la
version jour du modle et de cubicweb)
* `sqlcursor`, un curseur SQL pour les trs rares cas o il est rellement
ncessaire ou avantageux de passer par du sql
* `repo`, l'objet repository
Migration de schma
-------------------
Les fonctions de migration de schma suivantes sont disponibles dans les scripts
"repository" :
* `add_attribute(etype, attrname, attrtype=None, commit=True)`, ajoute un
nouvel attribut un type d'entit existante. Si le type de celui-ci n'est pas
spcifi il est extrait du schma jour.
* `drop_attribute(etype, attrname, commit=True)`, supprime un
attribut un type d'entit existante.
* `rename_attribute(etype, oldname, newname, commit=True)`, renomme un attribut
* `add_entity_type(etype, auto=True, commit=True)`, ajoute un nouveau type
d'entit. Si `auto` est vrai, toutes les relations utilisant ce type d'entit
et ayant un type d'entit connu l'autre extrmit vont galement tre
ajoutes.
* `drop_entity_type(etype, commit=True)`, supprime un type d'entit et toutes
les relations l'utilisant.
* `rename_entity_type(oldname, newname, commit=True)`, renomme un type d'entit
* `add_relation_type(rtype, addrdef=True, commit=True)`, ajoute un nouveau type
de relation. Si `addrdef` est vrai, toutes les dfinitions de relation de ce
type seront galement ajoutes.
* `drop_relation_type(rtype, commit=True)`, supprime un type de relation et
toutes les dfinitions de ce type.
* `rename_relation(oldname, newname, commit=True)`, renomme une relation.
* `add_relation_definition(subjtype, rtype, objtype, commit=True)`, ajoute une
dfinition de relation.
* `drop_relation_definition(subjtype, rtype, objtype, commit=True)`, supprime
une dfinition de relation.
* `synchronize_permissions(ertype, commit=True)`, synchronise les permissions
d'un type d'entit ou de relation
* `synchronize_rschema(rtype, commit=True)`, synchronise les proprits et
permissions d'un type de relation.
* `synchronize_eschema(etype, commit=True)`, synchronise les proprits et
permissions d'un type d'entit.
* `synchronize_schema(commit=True)`, synchronise le schma persistent avec le
schma jour (mais sans ajouter ni supprimer de nouveaux types d'entits ou
de relations ni de dfinitions de relation).
* `change_relation_props(subjtype, rtype, objtype, commit=True, **kwargs)`, change
les proprits d'une definition de relation en utilisant les arguments nomms
pour les proprits changer.
* `set_widget(etype, rtype, widget, commit=True)`, change le widget utiliser
pour la relation <rtype> du type d'entit <etype>
* `set_size_constraint(etype, rtype, size, commit=True)`, change la contrainte
de taille pour la relation <rtype> du type d'entit <etype>
Migration de donnes
--------------------
Les fonctions de migration de donnes suivantes sont disponibles dans les scripts
"repository" :
* `rqlexec(rql, kwargs=None, cachekey=None, ask_confirm=True)`, xcute une
requte rql arbitraire, d'interrogation ou de modification. Un objet result
set est retourn.
* `rqlexecall(rqliter, cachekey=None, ask_confirm=True)`, xcute une srie
de requtes rql arbitraires, d'interrogation ou de modification. rqliter est
un itrateur retournant des couples (rql, kwargs). Le result set de la
dernire requte xcute est retourn.
* `add_entity(etype, *args, **kwargs)`, ajoute une nouvelle entit du type
donnes. La valeur des attributs et relations est spcifie en utilisant les
arguments nomms et positionnels.
Cration de workflow
--------------------
Les fonctions de cration de workflow suivantes sont disponibles dans les scripts
"repository" :
* `add_state(name, stateof, initial=False, commit=False, **kwargs)`, ajoute un
nouvel tat de workflow
* `add_transition(name, transitionof, fromstates, tostate, requiredgroups=(), commit=False, **kwargs)`,
ajoute une nouvelle transtion de workflow
Migration de configuration
--------------------------
Les fonctions de migration de configuration suivantes sont disponibles dans tout
les scripts :
* `option_renamed(oldname, newname)`, indique qu'une option a t renomme
* `option_group_change(option, oldgroup, newgroup)`, indique qu'une option a
chang de groupe
* `option_added(oldname, newname)`, indique qu'une option a t ajoute
* `option_removed(oldname, newname)`, indique qu'une option a t supprime
Autres fonctions de migration
-----------------------------
Ces fonctions ne sont utiliss que pour des oprations de bas niveau
irralisables autrement ou pour rparer des bases casses lors de session
interactive. Elles sont disponibles dans les scripts "repository".
* `sqlexec(sql, args=None, ask_confirm=True)`, xcute une requte sql
arbitraire, n'utiliser
* `add_entity_type_table(etype, commit=True)`
* `add_relation_type_table(rtype, commit=True)`
* `uninline_relation(rtype, commit=True)`