Re: [capnproto] Schema Refactoring and Unique IDs

On Wed, Aug 2, 2023 at 11:51 PM Jonathan Shapiro wrote: > Kenton: Are the type IDs likely to have collided? > If the two files contain types with identical names, they will have identical IDs, as the default ID for a type is generated by taking a hash of the parent scope's ID together with the

Re: [capnproto] Schema Refactoring and Unique IDs

Kenton: Are the type IDs likely to have collided? Ian: If not, you might be able to hand-annotate the impacted types with the *already generated* IDs and then change the file ID. This offers the possibility of a clean changeover at the next breaking version change. Kenton: what *other* IDs will

Re: [capnproto] Schema Refactoring and Unique IDs

Yes, changing the file ID will change the IDs of all types declared within, unless they have explicitly declared their own IDs. This only really matters if you are using RPC. Type IDs of interfaces are part of the wire protocol. Type IDs of structs and enums are not really used for anything,

Re: [capnproto] Schema Refactoring and Unique IDs

Hi all, apologies for jumping on this thread a few years later. I have a similar question: suppose I have 2 different capnp files with the same file ID. # file foo.capnp 0xabbeabbeabbeabbe; struct Foo { val @0 : UInt32; }; # file bar.capnp 0xabbeabbeabbeabbe; struct Bar { val @1 :

Re: [capnproto] Schema Refactoring and Unique IDs

On Wed, Nov 25, 2020 at 3:43 PM Matt Stern wrote: > When I try to run capnp compile, I get the following: > > error: Import failed: /capnp/java.capnp > You will need to specify the same -I flags (import path) that you normally specify to `capnp compile` when running the Java code generator. If

Re: [capnproto] Schema Refactoring and Unique IDs

Great, thanks everyone. I will get the current unique ID from the capnp tool and specify it explicitly for my struct before I do my refactoring. On Wed, Nov 25, 2020, 5:26 PM Ian Denhardt wrote: > The ID doesn't affect the encoding itself, so the basic things will > still work. > > > You can

Re: [capnproto] Schema Refactoring and Unique IDs

The ID doesn't affect the encoding itself, so the basic things will still work. You can avoid changing the id by specifying it explicitly, e.g. struct Bar 0xfeefefffefeefefe { val @0 :UInt32; } You can discover the current id by running: capnp compile -ocapnp myschema.capnp Which will

Re: [capnproto] Schema Refactoring and Unique IDs

Thanks for the quick responses and clarifications! My actual schema file is compiled in C++ and Java. As such, it has the following preamble: using Cxx = import "/capnp/c++.capnp"; $Cxx.namespace("MyNamespace"); using Java = import "/capnp/java.capnp"; $Java.package("com.myorg");

Re: [capnproto] Schema Refactoring and Unique IDs

Erin is correct. For #2, the command-line syntax to have the compiler echo back capnp format (with all type IDs defined explicitly) is: capnp compile -ocapnp foo.capnp This of course requires that `capnp` and the generator plugin `capnpc-capnp` are in your $PATH, which they should be after

Re: [capnproto] Schema Refactoring and Unique IDs

1. This depends. The only places that the IDs get used "behind the scenes" are (a) those on interfaces are used in RPC calls to identify the interface and (b) when encoding schema annotations On the other hand, someone might be explicitly reading the ID from the schema file or the constant

[capnproto] Schema Refactoring and Unique IDs

Hi all, Suppose I have a simple schema file: 0xabbeabbeabbeabbe; struct Foo { val @0 : UInt32; }; struct Bar { val @1 : UInt32; }; I would like to move Bar into a separate schema file. If I understand the docs correctly, then this will