cubicweb issueshttps://forge.extranet.logilab.fr/cubicweb/cubicweb/-/issues2024-03-19T10:04:00Zhttps://forge.extranet.logilab.fr/cubicweb/cubicweb/-/issues/992Investigate readthedoc deprecation of mercurial2024-03-19T10:04:00ZArnaud VergnetInvestigate readthedoc deprecation of mercurialEmail from read the docs:
> Hello,
>
> You are receving this email because your Read the Docs project is impacted by an upcoming deprecation.
>
> We are discussing dropping of support for Bazaar, Mercurial and Subversion version syste...Email from read the docs:
> Hello,
>
> You are receving this email because your Read the Docs project is impacted by an upcoming deprecation.
>
> We are discussing dropping of support for Bazaar, Mercurial and Subversion version system controls. This means we will only support Git to do the initial clone and build your project's documentation. We would like your feedback on this change, to better understand if you can use Git for your project.
>
> We've made this decision because 99% of our users use Git and we can't cover the maintainance cost we were spending on Bazaar, Mercurial and SVN. Over time, these VCS tools have not gotten new features, and add confusion to users because not all our features work for them.
>
> Unfortunately, there is no workaround on the Read the Docs side that you can follow to keep building your documentation using these VCSs, but you could probably import your Subversion or Mercurial repository into GitHub or similar services to keep building on Read the Docs.
>
> The projects that are impacted by this change are:
>
> - `cubicweb`
> - `logilab-common`
> - `logilab-database`
> - `rql`
> - `yams`
>
> Please contact us or reply to this email if you have any questions, or think there is a strong reason we should continue to offer basic support for other VCS tools.
>
> Thanks, Read the Docs
>
> Keep documenting,
> Read the Docs
> https://readthedocs.orghttps://forge.extranet.logilab.fr/cubicweb/cubicweb/-/issues/117[cw3.28.2] problème pyramid2023-03-28T14:56:17ZKatia Saurfelt[cw3.28.2] problème pyramidIl semble que les routes pyramid sur get/delete rajoutent maintenant le "/" final sur l'url (à confirmer)
* [ ] rajouter un exemple dans ce ticket qui explique en quoi c'est un problème
* [ ] confirmer que c'est bien en 3.2...Il semble que les routes pyramid sur get/delete rajoutent maintenant le "/" final sur l'url (à confirmer)
* [ ] rajouter un exemple dans ce ticket qui explique en quoi c'est un problème
* [ ] confirmer que c'est bien en 3.28 et pas 3.27
* [ ] ajouter des tests
* [ ] corriger si nécessaire
exemple d'un test qui ne passe plus :
```
def test_get_json_accept(self):
with self.admin_access.repo_cnx() as cnx:
blog_entry = cnx.create_entity("BlogEntry", title="tmp", content="content")
user_account = cnx.create_entity("UserAccount", name="name")
cnx.add_relation(blog_entry.eid, "has_creator", user_account.eid)
cnx.commit()
url = "/blogentry/%d" % blog_entry.eid
# XXX dans cw 3.28 l'url doit être "/blogentry/%d/" % blog_entry.eid,
sinon on "webtest.app.AppError: Bad response: 302 Found (not 400)"
self.login()
res = self.webapp.get(url, headers={"accept": "application/json"})
self.assertEqual(res.headers["content-type"], "application/json")
data = res.json
self.assertEqual(data["content"], "content")
```
dans cw 3.28 l'url doit se termniner par un "/" :
` url = "/blogentry/%d/" % blog_entry.eid `
sinon on "webtest.app.AppError: Bad response: 302 Found (not 400)"Katia SaurfeltKatia Saurfelthttps://forge.extranet.logilab.fr/cubicweb/cubicweb/-/issues/356Avoid having to explictilty add the host url in pyramid.csrf_trusted_origins ...2023-01-24T13:42:15ZFrank BessouAvoid having to explictilty add the host url in pyramid.csrf_trusted_origins on instance served on non-"/" base urlsOn instances served on a non-"/" base url, POST requests made on form fail the pyramid's `check_csrf_origin` test. To fix that we have to add the domain name to the list of trusted origins in the pyramid.ini.
I think that we shoudln't ha...On instances served on a non-"/" base url, POST requests made on form fail the pyramid's `check_csrf_origin` test. To fix that we have to add the domain name to the list of trusted origins in the pyramid.ini.
I think that we shoudln't have to do that and that the host serving the application should automatically trust itself.https://forge.extranet.logilab.fr/cubicweb/cubicweb/-/issues/346are "test_one_each_config" kind of autotest/generated test useful?2021-08-03T13:24:51ZLaurent Peuchare "test_one_each_config" kind of autotest/generated test useful?Right now we have those automatically generated tests often called "test_one_each_config" which in theory seems like a great idea. But, we've encountered several issues with them:
- they are super slow (more than 5min on py3-web)
- we d...Right now we have those automatically generated tests often called "test_one_each_config" which in theory seems like a great idea. But, we've encountered several issues with them:
- they are super slow (more than 5min on py3-web)
- we don't understand them
- when they bug it's generally a nightmare to understand why and how and debugging is very hard
- I don't think anyone has been writing them anymore (everyone seems lost and scared when I mention them)
How could we improve this situation? Should we remove them instead or are they useful?
Related #339Nicolas Chauvatnicolas.chauvat@logilab.frNicolas Chauvatnicolas.chauvat@logilab.frhttps://forge.extranet.logilab.fr/cubicweb/cubicweb/-/issues/30Fix broken test on logilab-constraint or restraint the size of this project?2021-04-13T15:04:30ZLaurent PeuchFix broken test on logilab-constraint or restraint the size of this project?I've discovered that we actually have a library called logilab-constraint used by RQL and no one seems to be aware of it anymore (not work has been done on it since 2015).
And, sadly, tests are broken on it: https://forge.extranet.logil...I've discovered that we actually have a library called logilab-constraint used by RQL and no one seems to be aware of it anymore (not work has been done on it since 2015).
And, sadly, tests are broken on it: https://forge.extranet.logilab.fr/open-source/logilab-constraint/-/jobs/26065
I don't know how worth it is it to spent time on it and I'm not sure that much.
I haven't taken the time to inspect how it is used and why and if we can't simply can ditch it.https://forge.extranet.logilab.fr/cubicweb/cubicweb/-/issues/31on `add_entity_type` in CubicWeb it seems that __unique_together__ is ignored...2021-02-02T14:56:53ZLaurent Peuchon `add_entity_type` in CubicWeb it seems that __unique_together__ is ignored and the constraint not createdAs reported by @emartinet on riot, it seems that when a new entity is added using `add_entity_type` in CubicWeb the `__unique_together__` field is ignore and the constraint related to it isn't created while, when generating the schema th...As reported by @emartinet on riot, it seems that when a new entity is added using `add_entity_type` in CubicWeb the `__unique_together__` field is ignore and the constraint related to it isn't created while, when generating the schema the first time the constraint is correctly applied.
Those assumptions have been tested by @emartinet
Some related links into our projects:
* in YAMS where __unique_together__ is detected https://forge.extranet.logilab.fr/open-source/yams/blob/c37badc51adf56175e233d3b32f1898c0366217d/yams/schema.py#L264
* in CubicWeb where it is taken into account when generating SQL https://forge.extranet.logilab.fr/cubicweb/cubicweb/blob/527d2989602e80036b1c588cf732d9ae6126e61f/cubicweb/server/schema2sql.py#L97 https://forge.extranet.logilab.fr/cubicweb/cubicweb/blob/527d2989602e80036b1c588cf732d9ae6126e61f/cubicweb/server/schema2sql.py#L162-164
* the related call inside logilab-database https://forge.extranet.logilab.fr/open-source/logilab-database/blob/017334dac24ca86eb779bef1c61fce51af0ec003/logilab/database/__init__.py#L890-898
* `add_entity_type` definition inside CW https://forge.extranet.logilab.fr/cubicweb/cubicweb/blob/527d2989602e80036b1c588cf732d9ae6126e61f/cubicweb/schema.py#L1017-1035
* `add_entity_type` definition inside YAMS https://forge.extranet.logilab.fr/open-source/yams/blob/c37badc51adf56175e233d3b32f1898c0366217d/yams/schema.py#L1440-1459https://forge.extranet.logilab.fr/cubicweb/cubicweb/-/issues/49"Cubicweb-ctl upgrade --fs-only" cmd must not performe BD migrations and wri...2021-02-02T14:53:38ZKatia Saurfelt"Cubicweb-ctl upgrade --fs-only" cmd must not performe BD migrations and write new cubes versions in the DBIn case of cubes upgrade ```cubicweb-ctl upgrade instance --fs-only ``` do write new cubes versions in the base and possibly performes the migrations.
See the traceback bellow on a read-only postgres base:
```
usr/lib/python3/dist-pack...In case of cubes upgrade ```cubicweb-ctl upgrade instance --fs-only ``` do write new cubes versions in the base and possibly performes the migrations.
See the traceback bellow on a read-only postgres base:
```
usr/lib/python3/dist-packages/jinja2/runtime.py:318: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
from collections import Mapping
2020-06-05 13:47:02 - (cubicweb.sources.system) CRITICAL: no text index table
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cubicweb/cwctl.py", line 151, in run_arg
status = cmdmeth(appid) or 0
File "/usr/lib/python3/dist-packages/cubicweb/cwctl.py", line 771, in upgrade_instance
mih.migrate(vcconf, reversed(toupgrade), self.config)
File "/usr/lib/python3/dist-packages/cubicweb/server/migractions.py", line 172, in migrate
super(ServerMigrationHelper, self).migrate(vcconf, toupgrade, options)
File "/usr/lib/python3/dist-packages/cubicweb/migration.py", line 186, in migrate
self.cube_upgraded(cube, toversion)
File "/usr/lib/python3/dist-packages/cubicweb/server/migractions.py", line 157, in cube_upgraded
text_type(version))
File "/usr/lib/python3/dist-packages/cubicweb/server/migractions.py", line 1352, in cmd_set_property
prop.cw_set(value=value)
File "/usr/lib/python3/dist-packages/cubicweb/entity.py", line 1327, in cw_set
self._cw.execute(rql, qargs)
File "/usr/lib/python3/dist-packages/cubicweb/server/session.py", line 174, in check_open
return func(cnx, *args, **kwargs)
File "/usr/lib/python3/dist-packages/cubicweb/server/session.py", line 719, in execute
rset = self._execute(self, rql, kwargs, build_descr)
File "/usr/lib/python3/dist-packages/cubicweb/statsd_logger.py", line 121, in __call__
return self.callable(*args, **kw)
File "/usr/lib/python3/dist-packages/cubicweb/server/querier.py", line 565, in execute
results = plan.execute()
File "/usr/lib/python3/dist-packages/cubicweb/server/querier.py", line 187, in execute
result = step.execute()
File "/usr/lib/python3/dist-packages/cubicweb/server/ssplanner.py", line 525, in execute
repo.glob_update_entity(cnx, edited)
File "/usr/lib/python3/dist-packages/cubicweb/server/repository.py", line 846, in glob_update_entity
source.update_entity(cnx, entity)
File "/usr/lib/python3/dist-packages/cubicweb/server/sources/native.py", line 597, in update_entity
self.doexec(cnx, sql, attrs)
File "/usr/lib/python3/dist-packages/cubicweb/statsd_logger.py", line 121, in __call__
return self.callable(*args, **kw)
File "/usr/lib/python3/dist-packages/cubicweb/server/sources/native.py", line 684, in doexec
cursor.execute(str(query), args)
psycopg2.errors.ReadOnlySqlTransaction: ERREUR: ne peut pas exécuter UPDATE dans une transaction en lecture seule
instance francearchivesB not upgraded: ERREUR: ne peut pas exécuter UPDATE dans une transaction en lecture seule
Upgrading the instance francearchivesB
--------------------------------------
-> migration needed from 2.6.5 to 2.7.4 for francearchives
```https://forge.extranet.logilab.fr/cubicweb/cubicweb/-/issues/107[migration] add_relation don't take into account `required=True`2021-02-02T14:47:18ZFrançois Ferry[migration] add_relation don't take into account `required=True`How to reproduce this bug ?
* take one of your cube, add `poulet=String(required=True)` in one class schema declaration, and run `db-init`. If you ask postgresql, you should find that `poulet` is `NON-nullable` ;
* on an existing base, ...How to reproduce this bug ?
* take one of your cube, add `poulet=String(required=True)` in one class schema declaration, and run `db-init`. If you ask postgresql, you should find that `poulet` is `NON-nullable` ;
* on an existing base, add `poulet=String(required=True)` in one class schema declaration, and add this attribute in the shell with `add_attribute("MyClass", "poulet")`. If you ask postgresql, you should find that `poulet` can be NULL, while it shouldn't.
Cubicweb version 3.28, with postgresql 11