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.

Sign up for GitHub

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

Jump to bottom

Drop deprecated JSON.mapping #9527

Merged
merged 2 commits into from
Aug 3, 2020
Merged

Drop deprecated JSON.mapping #9527

merged 2 commits into from
Aug 3, 2020

Conversation

bcardiff
Copy link
Member

Use github:crystal-lang/json_mapping.cr as a drop-in replacement.

@bcardiff
Copy link
Member Author

The JSON::MappingError was shared between Mapping and Serializable.

Should I create a JSON::SerializableError or keep the old name?

@bcardiff bcardiff added this to the 1.0.0 milestone Jun 22, 2020
@asterite
Copy link
Member

I think JSON::SerializableError is fine.

@Sija
Copy link
Contributor

Sija commented Jun 22, 2020 •
edited
Loading

I'd suggest scoping that to JSON::Serializable::Error. There are many more examples of such convention already established - i.e. JSON::Error, Base64::Error, Compress::Gzip::Error, File::Error, and more...

@straight-shoota
Copy link
Member

Changing the name of the exception would introduce a breaking change. JSON::MappingError wasn't deprecated in 0.35.0, so I suppose it should be in 1.0.

Looking at YAML, there's just YAML::ParseException. But I suppose having a dedicated serialization exception woudl be a good idea for each, JSON and YAML.

@asterite
Copy link
Member

Nah, after a few months after 1.0.0 nobody will care about that small breaking change.

Plus the 1.0.0 release will break all shards so they will have to upgrade anyway.

@bcardiff
Copy link
Member Author

Names are not that tidy. The following exists [YAML|JSON]::ParseException and [YAML|JSON]::Error.

I would prefer to avoid using JSON::Serializable::Error and keep JSON::SerializableError

@bcardiff bcardiff merged commit 4853a7f into crystal-lang:master Aug 3, 2020
@bcardiff bcardiff deleted the cleanup/json-mapping branch August 3, 2020 13:10
This was referenced Mar 7, 2021
Merged
Merged
drhuffman12 added a commit to drhuffman12/couchdb.cr that referenced this pull request Sep 6, 2021
@drhuffman12
drhuffman12/upgrade_to_crystal_1.1.1 "json_mapping" is now a shard (c…
fe42248 
…rystal-lang/crystal#9527); (Refactor to use JSON::Serializable instead?)
This was referenced Sep 6, 2021
Closed
Merged
drhuffman12 added a commit to drhuffman12/couchdb.cr that referenced this pull request Sep 6, 2021
@drhuffman12
Drhuffman12/upgrade to crystal 1.1.1 (#1)
4e4c9b5 
* drhuffman12/upgrade_to_crystal_1.1.1 "json_mapping" is now a shard (crystal-lang/crystal#9527); (Refactor to use JSON::Serializable instead?)

* drhuffman12/upgrade_to_crystal_1.1.1 avoid "Missing ENV key" errors; add more db conn env var's

* drhuffman12/upgrade_to_crystal_1.1.1 TODO: Why "CouchDB::Response::Vendor#version" not getting parsed in?

* drhuffman12/upgrade_to_crystal_1.1.1 Allow CouchDB '3.x.x' (not just '2.x.x'). (TODO: Add applicable tests for '3.x.x' changes.); TODO: Why "CouchDB::Response::Vendor#version" not getting parsed in?

* drhuffman12/upgrade_to_crystal_1.1.1 Bump shard version to "0.4.0"; comment out Crystal version requirement (note compatibility elsewhere?)

* drhuffman12/upgrade_to_crystal_1.1.1 cleanup re `Vendor#version`

* drhuffman12/upgrade_to_crystal_1.1.1 Add myself as a contributor.
@drhuffman12 drhuffman12 mentioned this pull request Sep 6, 2021
Open
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@asterite asterite asterite approved these changes

Assignees
No one assigned
Labels
breaking-change topic:stdlib:serialization
Projects
None yet
Milestone
0.36.0
Development

Successfully merging this pull request may close these issues.
4 participants
@bcardiff @asterite @Sija @straight-shoota