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.

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

Code generation for variable-length data field #2

Closed
donmendelson opened this issue Nov 6, 2013 · 3 comments
Closed

Code generation for variable-length data field #2

donmendelson opened this issue Nov 6, 2013 · 3 comments

Comments

@donmendelson
Copy link

I generated Java code for a message schema with variable-length data. The generated code has functions set and get the length of the data but not a direct way to locate the data in the buffer or to populate it. Not sure how to use this. It seems to me that a method to set data into the field should also set its length.

The encoding is this:



The field is defined this way:

The generated code:

/* Generated SBE (Simple Binary Encoding) message codec */
package MarketData;

import java.nio.ByteOrder;
import java.util.;
import uk.co.real_logic.sbe.generation.java.
;

public class DATA implements FixedFlyweight
{
private DirectBuffer buffer;
private int offset;

public DATA reset(final DirectBuffer buffer, final int offset)
{
    this.buffer = buffer;
    this.offset = offset;
    return this;
}

public int size()
{
    return -1;
}

public int length()
{
    return CodecUtil.uint16Get(buffer, offset + 0, ByteOrder.LITTLE_ENDIAN);
}

public DATA length(final int value)
{
    CodecUtil.uint16Put(buffer, offset + 0, value, ByteOrder.LITTLE_ENDIAN);
    return this;
}

}

@donmendelson
Copy link
Author

Actually, the message flyweight class has has a method to set the data, which also writes the length. It doesn't seem to use the generated DATA class.

@tmontgomery
Copy link
Contributor

Can you send the XML schema for this?

It looks like this is only the length field and no place for the variable length data to go.

Usually the type looks like:

    <composite name="varDataEncoding">
        <type name="length" primitiveType="uint8" semanticType="Length"/>
        <type name="varData" primitiveType="uint8" length="0" characterEncoding="UTF-8" semanticType="data"/>
    </composite>

and a field like:

    <data name="make" id="17" type="varDataEncoding" semanticType="Make"/>

This is my understanding of the spec unless I've missed something crucial. It could be that the XML isn't being checked far enough to catch something.

Just FYI on usage....

Normally, when elements are used, they generate a set of methods that have "get" and "put" prepended to them for various ways of accessing them. Per element as well as using byte[]s in a Java way.

While we are working on doc, etc. you might check out the examples dir to get a feel for how it is used.
With the Car schema and SbeExample.java file. It has examples of the Model and Make fields and how they can be set and retrieved.

For example, encoding looks like:

car.putMake(MAKE, srcOffset, MAKE.length);

Decoding looks like:

car.getMake(buffer, 0, buffer.length)

@mjpt777
Copy link
Contributor

mjpt777 commented Nov 7, 2013

As Todd has described the var data fields should be set via the generated message encoder. All entry points to encoding or decoding of messages should be via the message type. See the following link for an example.

https://github.com/real-logic/simple-binary-encoding/blob/master/examples/java/uk/co/real_logic/sbe/examples/SbeExample.java

Note: The generated stub for the type you looked at does not have the field to set data because it is declared variable length, i.e. length = 0. This is generated for metadata purposes only because we need to know the the type of the field that contains the length of the var data value which can be different sized integers according to the spec.

@mjpt777 mjpt777 closed this as completed Nov 7, 2013
adam-talos added a commit to adam-talos/simple-binary-encoding that referenced this issue Dec 18, 2022
aeron-io#1: LibRsDef explicitly us crate:: to disambiguate from built in mods like bool
aeron-io#2: Added acting_version field to Composite structs to fix compilation errors when using Composite structs.  This is an incomplete implementation because the parent doesn't pass the acting_version to the composite because you need to change the signature of wrap(parent, offset) to include the acting_version, so this version just ensures that if the acting_version isn't set on the composite, it disregards the version check.
aeron-io#3: fixed primitiveArrayDecoder to return an empty array of the right size if less than version required.
suremarc pushed a commit to polygon-io/simple-binary-encoding that referenced this issue Jan 19, 2023
aeron-io#1: LibRsDef explicitly us crate:: to disambiguate from built in mods like bool
aeron-io#2: Added acting_version field to Composite structs to fix compilation errors when using Composite structs.  This is an incomplete implementation because the parent doesn't pass the acting_version to the composite because you need to change the signature of wrap(parent, offset) to include the acting_version, so this version just ensures that if the acting_version isn't set on the composite, it disregards the version check.
aeron-io#3: fixed primitiveArrayDecoder to return an empty array of the right size if less than version required.
SeanKim pushed a commit to SeanKim/simple-binary-encoding that referenced this issue Feb 21, 2023
aeron-io#1: LibRsDef explicitly us crate:: to disambiguate from built in mods like bool
aeron-io#2: Added acting_version field to Composite structs to fix compilation errors when using Composite structs.  This is an incomplete implementation because the parent doesn't pass the acting_version to the composite because you need to change the signature of wrap(parent, offset) to include the acting_version, so this version just ensures that if the acting_version isn't set on the composite, it disregards the version check.
aeron-io#3: fixed primitiveArrayDecoder to return an empty array of the right size if less than version required.
SeanKim pushed a commit to SeanKim/simple-binary-encoding that referenced this issue Mar 4, 2023
aeron-io#1: LibRsDef explicitly us crate:: to disambiguate from built in mods like bool
aeron-io#2: Added acting_version field to Composite structs to fix compilation errors when using Composite structs.  This is an incomplete implementation because the parent doesn't pass the acting_version to the composite because you need to change the signature of wrap(parent, offset) to include the acting_version, so this version just ensures that if the acting_version isn't set on the composite, it disregards the version check.
aeron-io#3: fixed primitiveArrayDecoder to return an empty array of the right size if less than version required.
mjpt777 pushed a commit that referenced this issue Nov 1, 2023
…ults for enums (#952)

* Fixed several issues:
#1: LibRsDef explicitly us crate:: to disambiguate from built in mods like bool
#2: Added acting_version field to Composite structs to fix compilation errors when using Composite structs.  This is an incomplete implementation because the parent doesn't pass the acting_version to the composite because you need to change the signature of wrap(parent, offset) to include the acting_version, so this version just ensures that if the acting_version isn't set on the composite, it disregards the version check.
#3: fixed primitiveArrayDecoder to return an empty array of the right size if less than version required.

* [Rust] removed 'acting_version' field from SubGroup decoder

* [Rust] updated RustGenerator::generateEnum() to support derive "Default" instead of generating impl

* fixed formatting issue

* [Rust] updated how 'use declarations' are generated to prevent "ambiguous glob re-exports" warnings from rust compiler

---------

Co-authored-by: Adam Krieg <[email protected]>
Co-authored-by: Michael Ward <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants