Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incompatibility with SQLAlchemy 1.3 #83

Open
gracinet opened this Issue Mar 9, 2019 · 2 comments

Comments

Projects
None yet
2 participants
@gracinet
Copy link
Contributor

gracinet commented Mar 9, 2019

Noticed this with the Travis builds of Anyblok / WMS Base falling. Restricting to SQLAlchemy<1.3 does indeed fix them.

I did not investigate further, but I'd be surprised if it were specific to AWB (Anyblok's build seems also to be currently broken on master).

  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/anyblok_nose/plugins.py", line 106, in load_registry
    registry = RegistryManager.get(db_name)
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/anyblok/registry.py", line 136, in get
    db_name, loadwithoutmigration=loadwithoutmigration, **kwargs)
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/anyblok/registry.py", line 434, in __init__
    self.load()
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/anyblok/logging.py", line 92, in f
    return function(*args, **kwargs)
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/anyblok/registry.py", line 946, in load
    raise e
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/anyblok/registry.py", line 942, in load
    blok2install) or mustreload
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/anyblok/registry.py", line 1069, in apply_model_schema_on_table
    self.migration.auto_upgrade_database()
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/anyblok/migration.py", line 985, in auto_upgrade_database
    report = self.detect_changed()
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/anyblok/migration.py", line 996, in detect_changed
    return MigrationReport(self, diff)
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/anyblok/migration.py", line 292, in __init__
    if fnct(diff):
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/anyblok/migration.py", line 179, in init_remove_ck
    self.raise_if_withoutautomigration()
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/anyblok/migration.py", line 42, in raise_if_withoutautomigration
    raise MigrationException("The metadata and the base structue are "
anyblok.migration.MigrationException: The metadata and the base structue are different, or this difference is forbidden in 'no auto migration' mode

@jssuzanne jssuzanne self-assigned this Mar 13, 2019

@jssuzanne jssuzanne added the bug label Mar 13, 2019

@jssuzanne jssuzanne added this to the 0.21.0 milestone Mar 13, 2019

@jssuzanne

This comment has been minimized.

Copy link
Member

jssuzanne commented Mar 13, 2019

Hi, Georges.

I saw it, I fixed it in the branch pytest, can you confirm that this branch fix it. I will pick it in master and release AnyBlok.

The problem come from the naming convention, since SQLAlchemy 1.3 the name of check constrainte is truncated and finished with a hash value.

the comparison method does not know the hash and can not determine that the truncated name and the full name are the same. What causes the destruction and recreation of the constraint

jssuzanne added a commit that referenced this issue Mar 15, 2019

@gracinet

This comment has been minimized.

Copy link
Contributor Author

gracinet commented Mar 20, 2019

Took me a while to get back to testing conditions, just gave it a new try: it seems to be fixed in 0.21.3, namely I could lauch all tests of Anyblok / Wms Base (AWB) successfully with SQLAlchemy 1.3.1

For the record, it's still there for me in branch pytest.

@jssuzanne, what would be your suggestion with respect to requirements for AWB ? Should I simply require AnyBlok >= 1.23.1 ? Would I need then to insist on SQLAlchemy >= 1.3 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.