Comments (9)
Also, just noticed that you're using proto2
syntax, for which this tool doesn't claim to make any support guarantees. It probably works fine since the proto parser used supports the syntax and abstracts some of the differences (I think). I just wanted to point that out in case it becomes an issue in the future.
from protolock.
I'd have to double check, but you can disable this by disabling strict mode. Run protolock with the --strict=false
and you should get the desired results.
What you describe is a breaking API change, however, as a client calling a generated method by the old name will no longer receive the value you intend them to unless they change their code.
It most likely won't cause any exceptions, but the tool still advises against the change without reserving the name in case you add this field back down the line and give it a different value than an existing client expects.
from protolock.
@nilslice I have tried it with --strict=false
but still I get the same error because as per the documentation also --strict=false
will not have an impact on this.
What you describe is a breaking API change, however, as a client calling a generated method by the old name will no longer receive the value you intend them to unless they change their code.
- As per my understanding client code will work fine because protobuf parser works on the
tag number
and not on the property name (I am keeping the tag number same), so old client code will still receive the value.
from protolock.
You're right - sorry, I'm on mobile only at the moment and misread the docs.
After dealing with large protobuf projects for a while, I have seen code break from a name-only change and find that this rule is important to follow. But if you think it should really be treated differently I would consider a PR, though would need to get feedback from my team and the other contributors who may already agree with the rule in place.
from protolock.
@cpeeyush - would adding this rule to be disabled when --strict
is false make more sense to you?
I'm happy to do this, as I see your point regarding true "breaking" changes. I typically don't run --strict
mode false. If you'd like to contribute it I would welcome the PR. Otherwise, I'm glad to make the change myself if we agree.
from protolock.
@cpeeyush - would adding this rule to be disabled when
--strict
is false make more sense to you?I'm happy to do this, as I see your point regarding true "breaking" changes. I typically don't run
--strict
mode false. If you'd like to contribute it I would welcome the PR. Otherwise, I'm glad to make the change myself if we agree.
@nilslice Yes, I agree to disable this check with --strict
false.
I would love to deep dive and submit a PR but right now I am not getting time to do that and honestly, I will take more time to modify your go lang
code because it will be my first encounter with the go lang
. So if you can do this change that would be awesome.
from protolock.
Ok, no problem. Thanks for opening the issue and making the suggestion.
Out of curiousity, what language(s) are you using protocol buffers with primarily?
from protolock.
Ok, no problem. Thanks for opening the issue and making the suggestion.
Out of curiousity, what language(s) are you using protocol buffers with primarily?
I am primarily using protocol buffers with java
and trying to use your protolock
library in my in-house schema registry to validate any schema change during the CI builds.
from protolock.
@cpeeyush - thanks for the response, that's good to know!
As I started to make the change for this, and re-read your initial issue, I realize I had misunderstood the situation you encountered, and the --strict
mode set to false
should still be your solution.
The reason is that your name change is okay to do, but you should reserve the old name so that it doesn't happen to provide a consumer with some new kind of data for a field that was previously being used for another kind of data.
The rule, NoChangingFieldNames
, is the one that is toggled by --strict
mode, and is the rule you probably want to allow changes.
In order to make this work, your local dev flow with protolock
would be:
- write your proto definition
- change the name of a field (
string name = 1
->string full_name = 1
) - reserve the field name
name
(reserved "name"
) - run
protolock status --strict=false
- observe no warnings reported
protolock commit --strict=false
I believe this will support the changes you're trying to make -- please let me know if that is not the case. The main concern here is that you still need to reserve the old field name after you change the field name to something new.
Closing this for now, but if this does in fact require some code changes, we can re-open.
from protolock.
Related Issues (20)
- Error building protolock on ppc64le HOT 2
- Processing a single file HOT 3
- Enum aliases not supported HOT 3
- Does protolock support proto2 ? HOT 1
- Propose to publish ARM64 binary in releases HOT 6
- Convert circleci jobs to GitHub Actions
- oneof structure is not persisted in protolock HOT 4
- Options not parsed at the Enum level HOT 2
- found "stream" but expected [rpc method] for a valid proto HOT 3
- Add artefacts to Maven repository HOT 7
- Update docker hub image HOT 3
- Allow ability to include proto files that are not in the root tree
- TestOrder consistently fails
- Nit: typo in info string for protolock cmd HOT 1
- [.gitignore] Remove "protolock" line or edit file to not filter out "cmd/protolock" HOT 1
- False positive in camelCase naming violation for EnumValueOptions builtin HOT 1
- Embedded comments confuse the parser HOT 7
- Deeply nested messages may conflict HOT 2
- Duplicate message names with different fields are considered valid HOT 3
- protolock status shows a lot of warnings
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 protolock.