Is there a way to automatically log any queries that involve a deprecated field (i.e. one with a non-null deprecation_reason)?
It'd be helpful to help work out whether a deprecated field was still in use or could be properly removed.
Related
I am trying to use protobuf for serialization with kafka. I understand that required is removed in protobuf for compatibility related issues.
As per this documentation, it should be either singular or repeated
As per this post refer least-upvoted-answer, optional is returned. I couldn't find the same in the above mentioned documentation.
My second question is that why there should always be a field modifier. If it is as per the specification, if I have a field which is neither repeated nor optional(I know it's always there, there is no need of has_field()), what should be the field modifier? Should I explicitly add as optional but that is required and not optional, never left out
In the docs for FieldMask the paths use the field names (e.g., foo.bar.buzz), which means renaming the message field names can result in a breaking change.
Why doesn't FieldMask use the field numbers to define the path?
Something like 1.3.1?
You may want to consider filing an issue on the GitHub protocolbuffers repo for a definitive answer from the code's authors.
Your proposal seems logical. Using names may be a historical artifact. There's a possibly relevant comment on an issue thread in that repo:
https://github.com/protocolbuffers/protobuf/issues/3793#issuecomment-339734117
"You are right that if you use FieldMasks then you can't safely rename fields. But for that matter, if you use the JSON format or text format then you have the same issue that field names are significant and can't be changed easily. Changing field names really only works if you use the binary format only and avoid FieldMasks."
The answer for your question lies in the fact FieldMasks are a convention/utility developed on top of the proto3 schema definition language, and not a feature of it (and that utility is not present in all of the language bindings)
While you’re right in your observation that it can break easily (as schemas tend evolve and change), you need to consider this design choice from a user friendliness POV:
If you’re building an API and want to allow the user to select the field set present inside the response payload (the common use case for field masks), it’ll be much more convenient for you to allow that using field paths, rather then binary fields indices, as the latter would force the user of the gRPC/protocol generated code to be “aware” of the schema. That’s not always the desired case when providing API as a code software packages.
While implementing this as a proto schema feature can allow the user to have the best of both worlds (specify field paths, have them encoded as binary indices) for binary encoding, it would also:
Complicate code generation requirements
Still be an issue for plain text encoding.
So, you can understand why it was left as an “external utility”.
I'm upgrading my codebase's ElasticSearch from 5.6 to 7.x due to some features I'd like to explore.
I'm currently using GoLang & "github.com/olivere/elastic/v5" specifically.
However, auto_generate_phrase_query has been depreciated, and AutoGeneratePhraseQueries no longer works on v7 ("github.com/olivere/elastic/v7").
I've read to use explicit quoted queries, what is the equivalent to that in olivere? is there no setting i can set to true/false in ES when making requests to achieve this? Must i explicitly wrap my queries in quotation marks? Surely there must be a proper way to do this...
I found this: https://www.elastic.co/guide/en/elasticsearch/reference/6.8/query-dsl-query-string-query.html
which states use [type=phrase] instead
In Olivere, i can set this via: Type("phrase"); is this a sufficient alternative?
The closest thing was actually using Phrase Queries. For anyone in the future coming back to find an answer.
The parameter _sort in hapi fhir 4.2 shows a strange behaviour. While a query without any conditions like /Procedure returns all existing procedures, a sorted query like /Procedure?_sort=date returns only procedures having a date != null.
From a developers perspective one might say: Ok, I don't have a value to sort by, so I can't make an assertation, but practically this makes the _sort parameter completely useless for fields that can be null.
Why is a value of Null not treated as the least possible value for the field, like in sql or other ?
I got through the Hapi fhir changelog, but havn't found this issue mentioned ( for me, it is an issue )
I know that sort parameters are based on search parameters. Does anyone know whether there is a chance to change this behaviour by any option in the searchparameter ?
I guess No :-(
Cheers
Christian
I am aware of this question.
I am considering using Protobuf 3 for a file format, due to its efficient encoding, explicit schema and wide support. However one part of the schema that is very inconvenient is that it doesn't allow required fields.
Google has its reasons for removing required fields in Protobuf 3. The problem they had is real (removing required fields is a breaking change), but their solution is nonsense.
Anyway my question is: Protobuf 3 allows you to add custom options for fields. Has anyone used that (or another method) to add unofficial support for required fields to Protobuf 3?
Do you want to have some implicit validation for your file format by using Protobuf, i.e. do you want the parsing of a file to fail if the required field does not exist in the data? If so, you may use the wrapper types, these will trigger an error if you try to read their value from a non-existing field.
Dropbox's Rust library supports annotations to do this!
(gogoproto.nullable)=false Generates non-nullable fields types
(rust.nullable)=false Generates oneofs as non-nullable (fail on deserialization)
(rust.err_if_default_or_unknown)=true Generates enums as non-zeroable (fail on deserialization)