Comments (5)
This makes me think we could revisit this / leaves this open until we have a better idea of the "functional validation" change.
from concerto.
Status: both serializations now work in Ergo. This leaves the questions about how we present the data model: (serialization/deserialization) to users for:
- In concerto validation: null in fields or fields that are absent / fields with a content or fields that are present
- how we present the same thing in the Ergo data model and type system: none / some
So in effect Ergo takes the interpretation that the data model is a field containing either null
or something, not that the field itself is present or absent.
I would love it if we could align the interpretation (changing that in Ergo is rather non-trivial, so my preference would be to switch the interpretation in Concerto).
I am moving this discussion to the Concerto repo.
from concerto.
@dselman @mttrbrts Would love to have your thoughts on this issue. I would love to sneak in this change into Concerto 1.0.
Concretely the change would be, for the Concerto model:
concept C{
o Integer a optional
o String b
}
Current behaviour:
validate { "$class" : "C", "b" : "Foo " } -> { "$class" : "C", "b" : "Foo " }
validate { "$class" : "C", "a" : null, "b" : "Foo " } -> { "$class" : "C", "b" : "Foo " }
New behaviour:
validate { "$class" : "C", "b" : "Foo " } -> { "$class" : "C", "a": null, "b" : "Foo " }
validate { "$class" : "C", "a" : null, "b" : "Foo " } -> { "$class" : "C", "a": null, "b" : "Foo " }
Some beliefs:
- For the purpose of validation etc. I don't think this changes anything fundamental.
- For Ergo it doesn't change anything, but the serialization is more consistent with the user code (e.g., users write
C{ a: none, b: "Foo" }
) - For JavaScript, truthy tests like
if (validated.a) { ... }
keep their semantics, but some other tests, e.g.,if (validated.a === null) { ... }
may change - For code generation (e.g., in Java) I think this is also more consistent (to be checked)
from concerto.
If I’ve understood the proposal, you’d like all optionals to be serialised as ‘null’ when absent in the JSON?
Some questions:
- will impact size of the documents (many AP models have many optionals)
- with the serialiser going away post v1 where would we do this? Using the Concerto API we validate the user JS object as-is. It seems awkward to have to specify null for potentially dozens of optionals.
- this seems stricter in terms of model evolution, in that removing an optional now breaks all instances. Not sure that is bad, but it is interesting.
from concerto.
If I’ve understood the proposal, you’d like all optionals to be serialised as ‘null’ when absent in the JSON?
Some questions:
- will impact size of the documents (many AP models have many optionals)
- with the serialiser going away post v1 where would we do this? Using the Concerto API we validate the user JS object as-is. It seems awkward to have to specify null for potentially dozens of optionals.
- this seems stricter in terms of model evolution, in that removing an optional now breaks all instances. Not sure that is bad, but it is interesting.
Hm.. interesting questions.
- Size of the JSON data -- I think this is in the noise, maybe I'm wrong? Do we really care about this level of optimisation?
- very very good question. I think this is the biggest one. Can we really get away without having some changes to the JSON post validation? (e.g., default values from the model?) If yes, then we might want to consider this quite carefully (or maybe it just becomes a moot point -- note we will still need a
JSON -validate+convert-> ErgoJSON / other things
path for Ergo (and different representations e.g., WASM). but that could be some other operation. - symmetrically, currently changing an optional to a non optional would break? I think this shifts what kind of evolution would be transparent or not... I hadn't thought of that.
from concerto.
Related Issues (20)
- LocalDateTime
- Update CTO grammar for Import Aliasing HOT 2
- Update CTO printer for Import Aliasing
- Optimizations for applying decorators on a model HOT 1
- Vocabularies don't support namespace-scoped decorators HOT 1
- Update runtime classes to understand import aliasing
- Serialization exception when declaring a default false boolean field
- Update concerto-core/serializer to understand aliased imports HOT 2
- Update concerto-core/introspector to understand aliased imports
- Update concerto-analysis rules to analyse aliased imports HOT 3
- Multiple occurence of imported type in importTypes statement
- Redefining an imported type is allowed HOT 3
- Update v4 concerto
- DCS with namespace target, don't apply decorators on top of the namespace. HOT 5
- Update docs about import aliasing usage
- Update concerto-analyser to support import aliasing
- Document / Clarify naming rules for identifiers HOT 4
- concerto-codegen supports import aliasing for Java HOT 1
- Compression for serialized objects HOT 1
- API: getActualImportTypeName() in model Flle in aliasing
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from concerto.