Skip to content

Support DataJoint 2.x attribute-type spellings (backward compatible with 0.14.x) - #47

Open
akshay-jaggi wants to merge 4 commits into
datajoint:mainfrom
akshay-jaggi:compat-fixes
Open

Support DataJoint 2.x attribute-type spellings (backward compatible with 0.14.x)#47
akshay-jaggi wants to merge 4 commits into
datajoint:mainfrom
akshay-jaggi:compat-fixes

Conversation

@akshay-jaggi

@akshay-jaggi akshay-jaggi commented Aug 6, 2026

Copy link
Copy Markdown

One attribute-type spelling used by this element was removed or changed in
DataJoint 2.x. It has a replacement that works identically on 0.14.x, so this can
go in without waiting on a full 2.x migration.

Why now

DataJoint 2.0.0 shipped 2026-02-03 and 2.3.2 is current. install_requires
here says datajoint>=0.13, so a fresh install today resolves 2.x and the
element cannot even be imported:

>>> import element_event.event
AttributeError: module 'datajoint' has no attribute 'schema'. Did you mean: 'Schema'?
  element_event/event.py:7   schema = dj.schema()

What this changes

  • schema = dj.schema() in event.py and trial.py
construct 0.14.9 2.3.2
dj.schema → dj.Schema works — literally the same object in 0.14.9 required; AttributeError at import

Verified by activating the element against MySQL under datajoint 0.14.9 and
2.3.2 in turn.

What this deliberately does not change

longblob. It also has to change for 2.x — and much more urgently, because
under 2.x a longblob attribute silently stores str(array) rather than the
array — but <blob> is rejected by 0.14.9, so shipping it here would break
current users. It is on a separate branch and written up in the accompanying issue.

Applied mechanically with regexes rather than typed by hand, then reviewed. No
behaviour is changed, only spellings. Happy to reshape or split this however you
prefer.

@akshay-jaggi
Make the schema declarations work on DataJoint 2.x, without breaking …
113159b 
…0.14.x

DataJoint 2.0 (2026-02-03) is a rewrite, and three spellings this element uses
no longer work on it:

  `dj.schema`      removed in favour of `dj.Schema`. Importing the module
                   raises `AttributeError: module 'datajoint' has no attribute
                   'schema'` before any table is declared.
  `boolean`        rejected at declaration: `Unsupported attribute type`.
  `enum("x", "y")` the 2.x parser passes double-quoted values through verbatim
                   and emits invalid SQL, so declaration dies with a MySQL
                   syntax error.

In this element:

- `dj.schema()` -> `dj.Schema()` in `event.py`, `trial.py`

All three are **backward compatible**. In 0.14.9 `dj.schema` and `dj.Schema`
are the same object, and both `bool` and single-quoted `enum` have always been
accepted. Verified by activating the element against MySQL under datajoint
0.14.9 and 2.3.2.

Applied mechanically with regexes, not by hand. Deliberately does NOT touch
`longblob`, which also needs to change for 2.x but has no 0.14.x-compatible
spelling; that lives on the separate `datajoint-2.x` branch.
@akshay-jaggi
Port the table definitions to DataJoint 2.x: longblob -> <blob>
0db05f7 
On DataJoint 2.x a `longblob` attribute is a raw native column. It declares
cleanly and inserts succeed, but a numpy array written to it is returned as
`bytes`, with no error and no warning:

    longblob  -> returned type: bytes    round-trip OK: False
    <blob>    -> returned type: ndarray  round-trip OK: True

Rewrites all 3 `longblob` attribute declarations to the `<blob>` codec, which
restores 0.14.x serialisation behaviour.

This is 2.x-only and cannot be upstreamed as-is: 0.14.9 rejects `<blob>` with
`Support for Adapted Attribute types is disabled`. It therefore sits on this
branch rather than on `compat-fixes`, which stays installable on both lines.

Also adds a README section explaining what this branch is and how the two
branches relate.
Copilot AI lite review requested due to automatic review settings August 6, 2026 21:45
@akshay-jaggi akshay-jaggi mentioned this pull request Aug 6, 2026
Open
Copilot AI reviewed Aug 6, 2026
View reviewed changes

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates the element’s DataJoint schema initialization to be compatible with DataJoint 2.x (while remaining compatible with DataJoint 0.14.x), preventing import-time failures on fresh installs that resolve DataJoint 2.x.

Changes:

  • Replace schema = dj.schema() with schema = dj.Schema() in element_event/event.py.
  • Replace schema = dj.schema() with schema = dj.Schema() in element_event/trial.py.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
element_event/event.py Switch schema construction to dj.Schema() to avoid dj.schema import-time AttributeError on DataJoint 2.x.
element_event/trial.py Same schema construction update for DataJoint 2.x compatibility.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@dimitri-yatsenko

dimitri-yatsenko commented Aug 8, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

Thanks for this, and for the report in #48 — the diagnosis there is correct.
I traced it upstream and filed the DataJoint-side half as
datajoint/datajoint-python#1527.

I'd like to redirect this PR rather than merge it.

We are not keeping elements working on both 0.14.x and 2.x. A schema is either
2.x or pre-2.x, the two are not interoperable, DataJoint no longer supports pre-2.x,
and all schemas should be migrated. So the constraint that kept <blob> off this
branch does not apply — please send the full migration as a single PR instead.

There is no other 2.x failure in this element to act as a backstop. After this PR it
declares cleanly under 2.x and its 3 longblob attributes silently corrupt on insert.
The import error you removed is the only thing currently preventing that.

Remaining work for the full PR

count
longblob → <blob> 3 the data-loss fix
int / smallint → int32 / int16 2 works today, but native; warns
float → float32 9 same

Also raise the DataJoint floor — requirements.txt datajoint>=0.13 → datajoint>=2.3. That unpinned floor is
the root cause: it is what makes a fresh install resolve 2.x in the first place.

Please work from the migration guide rather than from this comment — it is the
authoritative version: Migrate to DataJoint 2.0.
It covers the legacy → 2.0 type mapping (longblob → <blob>, attach → <attach>,
and the @store variants), the :<blob>: column-comment marker that is the mechanism
behind the bug, the four-phase structure, and the case for creating tests before
migrating. What you have on your branch is Phase I — code only, against empty _v2
schemas, no impact on existing data. Migrating existing data is Phase III and separate.

There is no tests/ directory here and CI runs black and flake8 only, so your
manual verification is the only check that ran and nothing will catch a regression later.

Happy to review the full 2.x PR as soon as you open it. I'd suggest closing this one in
favour of that, or reusing this branch and pushing the rest onto it — your call, leaving
it open for you to decide.

@akshay-jaggi
Convert native numeric types to DataJoint 2.0 core types; raise dataj…
86104c0 
…oint floor

Per https://docs.datajoint.com/how-to/migrate-to-v20/ 's type mapping:
smallint->int16, int->int32, float->float32. 2 smallint and 9 float
attributes, across event.py and trial.py. Verified against a real MySQL 9.7.1
server under datajoint 2.3.2.

requirements.txt: datajoint>=0.13 -> datajoint>=2.3.

This branch already carried the <blob> conversion (3 attributes) and
dj.schema -> dj.Schema; this commit is the remainder of the migration. No
boolean or double-quoted enum in this package.

Completes datajoint#48 / datajoint#47.
@akshay-jaggi
README: describe the full migration, not the two-branch split
17ac937 
The upstream maintainer asked for one full-migration branch rather than a
compat-fixes/datajoint-2.x split (see the linked issue/PR threads). Both
branch names now carry the same content; this documents why and lists the
complete scope.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

Copilot code review Copilot
Copilot review effort
Applies to this pull request for everyone.Learn more about Copilot code review.
Copilot left review comments

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@akshay-jaggi @dimitri-yatsenko