feat!: Component.local_key -> Component.component_code#544
Conversation
kdmccormick
force-pushed
the
kdmccormick/keys-collection
branch
from
1489024 to
9875433
Compare
kdmccormick
force-pushed
the
kdmccormick/keys-component
branch
from
944a2c3 to
fbe4b4b
Compare
kdmccormick
force-pushed
the
kdmccormick/keys-collection
branch
from
b3daece to
d55764c
Compare
kdmccormick
force-pushed
the
kdmccormick/keys-component
branch
3 times, most recently
from
0f875ed to
2bf60ff
Compare
kdmccormick
force-pushed
the
kdmccormick/keys-component
branch
from
2bf60ff to
382a7b3
Compare
bradenmacdonald
left a comment
bradenmacdonald
left a comment
There was a problem hiding this comment.
Thanks, looks great! I did not test this, just read the code.
ormsbee
left a comment
ormsbee
left a comment
There was a problem hiding this comment.
Just a question about backwards compatibility. I'm not sure it's a blocker, but I would like to understand it better.
| if hasattr(entity, "component"): | ||
| component = entity.component | ||
| component_table = tomlkit.table() | ||
| # Write component_type and component_code explicitly so that restore | ||
| # (Verawood and later) does not need to parse the entity key. | ||
| component_table.add("component_type", str(component.component_type)) | ||
| component_table.add("component_code", component.component_code) | ||
| entity_table.add("component", component_table) |
There was a problem hiding this comment.
Question: What happens when an Ulmo instance reads this?
There was a problem hiding this comment.
I mean, I get that it won't understand the new component_code piece. But does it successfully import components that have an explicit [component] section, since that wasn't being written to the TOML previously?
There was a problem hiding this comment.
Hm, I'm currently hitting an issue where any archive which I unzip or re-zip fails to restore, regardless of whether I edit the contents or not, with the message Errors encountered during restore: package.toml: Missing learning package file. Archive that are never unzipped restore fine. I'm seeing this on the Ulmo sandbox, and I'm zipping using macOS's built in "Compress" utility. I'll try it later locally and see if I can get logs, and will try re-zipping with other methods....
There was a problem hiding this comment.
Haven't figured out this ⬆️ issue yet, but I did verify through unit tests that [component] and [container] seem safe to add without breaking Ulmo: #552
There was a problem hiding this comment.
Hm, I'm currently hitting an issue where any archive which I unzip or re-zip fails to restore, regardless of whether I edit the contents or not, with the message Errors encountered during restore: package.toml: Missing learning package file.
ah, duh, I was making a ZIP where collection, entities and package.toml were nested within a top-level rather than being top-level items themselves.
with that figured out, I verified manually that [component] and [container] are safe to add 👍🏻
There was a problem hiding this comment.
Ohp, just realized I should be testing [entity.component] and [entity.container]. Testing now
Renames the Component.local_key field to component_code, switching from key_field() to code_field() (stricter validation: [A-Za-z0-9\-\_\.]+, max_length=255). Updates all API call sites, backup/restore, and tests. Backup/restore now writes an [entity.component] section in each component TOML file containing component_type and component_code explicitly, so that restore does not need to parse the entity key. Old archives (without the [entity.component] section) are still accepted by falling back to the existing entity key parsing. BREAKING CHANGE: Component.local_key has been renamed to Component.component_code. BREAKING CHANGE: Component.component_code now validates against [A-Za-z0-9\-\_\.]+ and has a max_length of 255. Previously local_key used key_field() (no regex validation, max_length=500). BREAKING CHANGE: Function parameters renamed from local_key to component_code in create_component(...) and create_component_and_version(...). BREAKING CHANGE: Functions get_component_by_key(...)/component_exists_by_key(...), renamed to get_component_by_code(...)/component_exists_by_code(...), and parameters renamed from local_key to component_code. Part of: #322 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
kdmccormick
force-pushed
the
kdmccormick/keys-component
branch
from
70009c5 to
d7dc148
Compare
kdmccormick
force-pushed
the
kdmccormick/keys-component
branch
from
d7dc148 to
13cad83
Compare
3 participants
Description
BREAKING CHANGE: Component.local_key has been renamed to
Component.component_code.
BREAKING CHANGE: Component.component_code now validates against
[A-Za-z0-9-_.]+ and has a max_length of 255. Previously local_key used
key_field() (no regex validation, max_length=500).
BREAKING CHANGE: Function parameters renamed from local_key to component_code
in create_component(...) and create_component_and_version(...).
BREAKING CHANGE: Functions
get_component_by_key(...)/component_exists_by_key(...), renamed to
get_component_by_code(...)/component_exists_by_code(...), and parameters
renamed from local_key to component_code.
Backup-restore format is unchanged. component_type and component_code
will continue to be parsed from the entity key. This may change in
a future "v2" backup format.
Part of: #322
Full series of PRs:
keysare now opaquerefs#546Testing, AI Usage, and Merge Considerations
See #322