Fix sorting key for rdefs in schema viewer
With changeset 234ca3cbbb46, clicking in the schema of an entity with
cubicweb in py3 on "vue en boite" will probably result in an infinite
spinner (which implies cw > 3.26)
What happened ?
This "vue en boite" used to work at least until...
hg diff -c a8c1ea390400 cubicweb/schema.py
@@ -993,10 +992,6 @@ class CubicWebRelationSchema(PermissionM
return False
return True
- @deprecated('use .rdef(subjtype, objtype).role_cardinality(role)')
- def cardinality(self, subjtype, objtype, target):
- return self.rdef(subjtype, objtype).role_cardinality(target)
-
class CubicWebSchema(Schema):
"""set of entities and relations schema defining the possible data sets
But, wait ...
If I open a shell on an instance of cw 3.24 something seems off
>>> list(schema['CWUniqueTogetherConstraint'].relation_definitions())[0][0].cardinality
# <bound method CubicWebRelationSchema.wrapped of <constraint_of [CWUniqueTogetherConstraint,CWEType]>>
We have been sorting on a method the whole time ? Is it possible what
were the effects ?
1) We cannot sort function can't we ?
>>> def adder(i): return lambda x: x+i
>>> sorted(map(adder,range(10)))
[<function __main__.<lambda>>,
<function __main__.<lambda>>,
...
Yes we can.
2) what does it means.
>>> { adder(1) : 1 }
Out[19]: {<function __main__.<lambda>>: 1}
In fact the function object as a __hash__ method (which is practical for making
memoizers (cache)), and return truly random results (pseudo random).
My take on this patch is relations have NEVER been sorted by cardinality.
No one never ever noticed. Hence, I propose to not fix a bug that never was
reported.
CubicWeb semantic web framework
===============================
CubicWeb is a entities / relations based knowledge management system
developped at Logilab.
This package contains:
- a repository server
- a RQL command line client to the repository
- an adaptative modpython interface to the server
- a bunch of other management tools
Install
-------
More details at https://cubicweb.readthedocs.io/en/3.26/book/admin/setup
Getting started
---------------
Execute::
python3 -m venv venv
source venv/bin/activate
pip install 'cubicweb[pyramid]' cubicweb-blog
cubicweb-ctl create blog myblog
# read how to create your ~/etc/cubicweb.d/myblog/pyramid.ini file here:
# https://cubicweb.readthedocs.io/en/latest/book/pyramid/settings/#pyramid-settings-file
# then start your instance:
cubicweb-ctl pyramid -D myblog
sensible-browser http://localhost:8080/
Details at https://cubicweb.readthedocs.io/en/3.26/tutorials/base/blog-in-five-minutes
You can also look at the latest builds on Logilab's jenkins:
https://jenkins.logilab.org/
Test
----
Simply run the `tox` command in the root folder of this repository:
tox
How to install tox: https://tox.readthedocs.io/en/latest/install.html
Documentation
-------------
Look in the doc/ subdirectory or read https://cubicweb.readthedocs.io/en/3.26/
CubicWeb includes the Entypo pictograms by Daniel Bruce — http://www.entypo.com
Contributing
------------
Patches should be submitted by email at the cubicweb-devel@lists.cubicweb.org
mailing list in order to get reviewed by project integrators or any community
member.
The simplest way of send patches is to use the ``hg email`` command available
through the *patchbomb* extension of Mercurial. Preferably, patches should be
*in the message body* of emails. When submitting a revised version of a patch
series, a prefix indicating the iteration number ``<n>`` of the series should
be added to email subject prefixes; this can be achieved by specifying a
``--flag v<n>`` option to ``hg email`` command. If needed you can also use the
--in-reply-to option.
Examples:
hg email --to cubicweb-devel@lists.cubicweb.org --intro -r <start>::<end>
hg email --flag V2 --to cubicweb-devel@lists.cubicweb.org -r <start>::<end>
If you have any questions you can also come on Logilab's public XMPP room using
a XMPP client: public@conference.jabber.logilab.org
Mailing list: https://lists.cubicweb.org/mailman/listinfo/cubicweb-devel
Patchbomb extension: https://www.mercurial-scm.org/wiki/PatchbombExtension
Good practice on sending email patches: https://www.mercurial-scm.org/wiki/ContributingChanges#Emailing_patches