riakc_pb_socket:use_native_encoding/2 needs to be per-client, not process-wide [JIRA: CLIENTS-794]

[erikleitch]

Modifications to support t2b encoding on the client-side included adding a call to set the encoding, via: riakc_pb_socket:use_native_encoding(Client, UseNativeEncoding). This function sends a message to the server to toggle the encoding on a per-connection basis, but also stores the encoding in the process dictionary on the calling process' side.

This latter logic is erroneous: for example if you instantiate two clients in the same process, and set the encoding differently for each one, only the last state is stored in the calling process' process dictionary. The state is process-wide instead of per-client-connection.

The code should be reworked so that the encoding type for each client is stored in metadata carried by the client object, not in the process dictionary for the calling process.

[Basho-JIRA]

In a set of PRs that I'm about to unleash on the world, I've conceptually reworked how T2B message encoding is handled, from a separate protocol that is imposed on top of the same set of messages used for PB encoding, to a protocol that is linked to to a separate set of messages. In short, PB messages use PB-encoding, and T2B messages use T2B-encoding.

What this means is that clients can now do whatever they want -- they can happily send interleaved PB and T2B messages if they want to, for example (and also that sending the encoding toggle message is no longer necessary).

So there are now (at least) three ways of solving the particular problem that I created this issue for:

• when a client is instantiated, what we currently get is a Pid. when use_native_encoding(Pid, Use) is called, we store a per-Pid entry in the process dictionary that gets used whenever riakc_ts:put and riakc_ts:query are called, to decide behind the scenes which encoding scheme to use. This is the approach I've taken, because it is the smallest deviation from what we currently have implemented. However it still requires a process-dictionary lookup every time put and query are called, which is not ideal
• when a client is instantiated, what is returned is an object that contains the Pid, as well as metadata about that Pid, like the desired encoding type _This is more optimal than a dictionary lookup, but means that the exported interface to riakc_ts would fundamentally change. This could break somebody's erlang code that uses the returned Pid directly rather than using the return of riakc_pb_socket:startlink/2 as an opaque type
• we could get rid of the concept of a per-client encoding altogether, and have variants of put and query that allow different encodings.
  This would be the most performant way of doing it, is non-invasive in terms of changing the riakc interface, but give the freedom (and therefore puts the onus) of specifying an encoding on the user

(the latter could be implemented even if we still choose to do one of the first two options)

Thoughts?

_[posted via JIRA by Erik Leitch]_

[Basho-JIRA]

In a set of PRs that I'm about to unleash on the world, I've conceptually reworked how T2B message encoding is handled, from a separate protocol that is imposed on top of the same set of messages used for PB encoding, to a protocol that is linked to to a separate set of messages. In short, PB messages use PB-encoding, and T2B messages use T2B-encoding.

What this means is that clients can now do whatever they want -- they can happily send interleaved PB and T2B messages if they want to, for example (and also that sending the encoding toggle message is no longer necessary).

So there are now (at least) three ways of solving the particular problem that I created this issue for:

• when a client is instantiated, what we currently get is a Pid. when use_native_encoding(Pid, Use) is called, we store a per-Pid entry in the process dictionary that gets used whenever riakc_ts:put and riakc_ts:query are called, to decide behind the scenes which encoding scheme to use. This is the approach I've taken, because it is the smallest deviation from what we currently have implemented. However it still requires a process-dictionary lookup every time put and query are called, which is not ideal
• when a client is instantiated, what is returned is an object that contains the Pid, as well as metadata about that Pid, like the desired encoding type _This is more optimal than a dictionary lookup, but means that the exported interface to riakc_ts would fundamentally change. This could break somebody's erlang code that uses the returned Pid directly rather than using the return of riakc_pb_socket:startlink/2 as an opaque type
• we could get rid of the concept of a per-client encoding altogether, and have variants of put and query that allow different encodings.
  This would be the most performant way of doing it, is non-invasive in terms of changing the riakc interface, but gives the freedom (and therefore puts the onus) of specifying an encoding on the user

(the latter could be implemented even if we still choose to do one of the first two options)

Thoughts?

_[posted via JIRA by Erik Leitch]_

[Basho-JIRA]

In a set of PRs that I'm about to unleash on the world, I've conceptually reworked how T2B message encoding is handled, from a separate protocol that is imposed on top of the same set of messages used for PB encoding, to a protocol that is linked to to a separate set of messages. In short, PB messages use PB-encoding, and T2B messages use T2B-encoding.

What this means is that clients can now do whatever they want -- they can happily send interleaved PB and T2B messages if they want to, for example (and also that sending the encoding toggle message is no longer necessary).

So there are now (at least) three ways of solving the particular problem that I created this issue for:

• when a client is instantiated, what we currently get is a Pid. when use_native_encoding(Pid, Use) is called, we store a per-Pid entry in the process dictionary that gets used whenever riakc_ts:put and riakc_ts:query are called, to decide behind the scenes which encoding scheme to use. This is the approach I've taken, because it is the smallest deviation from what we currently have implemented. However it still requires a process-dictionary lookup every time put and query are called, which is not ideal
• when a client is instantiated, what is returned is an object that contains the Pid, as well as metadata about that Pid, like the desired encoding type _This is more optimal than a dictionary lookup, but means that the exported interface to riakc_ts would fundamentally change. This could break somebody's erlang code that uses the returned Pid directly rather than using the return of riakc_pb_socket:start_link/2 as an opaque type_
• we could get rid of the concept of a per-client encoding altogether, and have variants of put and query that allow different encodings.
  This would be the most performant way of doing it, is non-invasive in terms of changing the riakc interface, but gives the freedom (and therefore puts the onus) of specifying an encoding on the user

(the latter could be implemented even if we still choose to do one of the first two options)

Thoughts?

_[posted via JIRA by Erik Leitch]_

[Basho-JIRA]

In a set of PRs that I'm about to unleash on the world, I've conceptually reworked how T2B message encoding is handled, from a separate protocol that is imposed on top of the same set of messages used for PB encoding, to a protocol that is linked to to a separate set of messages. In short, PB messages use PB-encoding, and T2B messages use T2B-encoding.

What this means is that clients can now do whatever they want -- they can happily send interleaved PB and T2B messages if they want to, for example (and also that sending the encoding toggle message is no longer necessary).

So there are now (at least) three ways of solving the particular problem that I created this issue for:

• when a client is instantiated, what we currently get is a Pid. when use_native_encoding(Pid, Use) is called, we store a per-Pid entry in the process dictionary that gets used whenever riakc_ts:put and riakc_ts:query are called, to decide behind the scenes which encoding scheme to use. This is the approach I've taken, because it is the smallest deviation from what we currently have implemented. However it still requires a process-dictionary lookup every time put and query are called, which is not ideal
• when a client is instantiated, what is returned is an object that contains the Pid, as well as metadata about that Pid, like the desired encoding type _This is more optimal than a dictionary lookup, but means that the exported interface to riakc_ts would fundamentally change. This could break somebody's erlang code that uses the returned Pid directly rather than using the return of riakc_pb_socket:start_link/2 as an opaque type_
• we could get rid of the concept of a per-client encoding altogether, and have variants of put and query that allow different encodings.
  This would be the most performant way of doing it, is non-invasive in terms of changing the {code:java} riakc {code} interface, but gives the freedom (and therefore puts the onus) of specifying an encoding on the user

(the latter could be implemented even if we still choose to do one of the first two options)

Thoughts?

_[posted via JIRA by Erik Leitch]_

[Basho-JIRA]

In a set of PRs that I'm about to unleash on the world, I've conceptually reworked how T2B message encoding is handled, from a separate protocol that is imposed on top of the same set of messages used for PB encoding, to a protocol that is linked to to a separate set of messages. In short, PB messages use PB-encoding, and T2B messages use T2B-encoding.

What this means is that clients can now do whatever they want -- they can happily send interleaved PB and T2B messages if they want to, for example (and also that sending the encoding toggle message is no longer necessary).

So there are now (at least) three ways of solving the particular problem that I created this issue for:

• when a client is instantiated, what we currently get is a Pid. when {{use_native_encoding(Pid, Use)}} is called, we store a per-Pid entry in the process dictionary that gets used whenever riakc_ts:put and riakc_ts:query are called, to decide behind the scenes which encoding scheme to use. This is the approach I've taken, because it is the smallest deviation from what we currently have implemented. However it still requires a process-dictionary lookup every time put and query are called, which is not ideal
• when a client is instantiated, what is returned is an object that contains the Pid, as well as metadata about that Pid, like the desired encoding type _This is more optimal than a dictionary lookup, but means that the exported interface to riakc_ts would fundamentally change. This could break somebody's erlang code that uses the returned Pid directly rather than using the return of riakc_pb_socket:start_link/2 as an opaque type_
• we could get rid of the concept of a per-client encoding altogether, and have variants of put and query that allow different encodings.
  This would be the most performant way of doing it, is non-invasive in terms of changing the riakc interface, but gives the freedom (and therefore puts the onus) of specifying an encoding on the user

(the latter could be implemented even if we still choose to do one of the first two options)

Thoughts?

_[posted via JIRA by Erik Leitch]_

[Basho-JIRA]

In a set of PRs that I'm about to unleash on the world, I've conceptually reworked how T2B message encoding is handled, from a separate protocol that is imposed on top of the same set of messages used for PB encoding, to a protocol that is linked to to a separate set of messages. In short, PB messages use PB-encoding, and T2B messages use T2B-encoding.

What this means is that clients can now do whatever they want -- they can happily send interleaved PB and T2B messages if they want to, for example (and also that sending the encoding toggle message is no longer necessary).

So there are now (at least) three ways of solving the particular problem that I created this issue for:

• when a client is instantiated, what we currently get is a Pid. when {{use_native_encoding(Pid, Use)}} is called, we store a per-Pid entry in the process dictionary that gets used whenever {{riakc_ts:put}} and {{riakc_ts:query}} are called, to decide behind the scenes which encoding scheme to use. This is the approach I've taken, because it is the smallest deviation from what we currently have implemented. However it still requires a process-dictionary lookup every time {{put}} and {{query}} are called, which is not ideal
• when a client is instantiated, what is returned is an object that contains the Pid, as well as metadata about that Pid, like the desired encoding type _This is more optimal than a dictionary lookup, but means that the exported interface to {{riakc_ts}} would fundamentally change. This could break somebody's erlang code that uses the returned Pid directly rather than using the return value of {{riakc_pb_socket:startlink/2}} as an opaque type
• we could get rid of the concept of a per-client encoding altogether, and have variants of {{put}} and {{query}} that allow different encodings.
  This would be the most performant way of doing it, is non-invasive in terms of changing the {{riakc}} interface, but gives the freedom (and therefore puts the onus) of specifying an encoding on the user

(Note: the latter could also be implemented in addition to either of the first two options)

Thoughts?

_[posted via JIRA by Erik Leitch]_

[Basho-JIRA]

In a set of PRs that I'm about to unleash on the world, I've conceptually reworked how T2B message encoding is handled, from a separate protocol that is imposed on top of the same set of messages used for PB encoding, to a protocol that is linked to to a separate set of messages. In short, PB messages use PB-encoding, and T2B messages use T2B-encoding.

What this means is that clients can now do whatever they want -- they can happily send interleaved PB and T2B messages if they want to, for example (and also that sending the encoding toggle message is no longer necessary).

So there are now (at least) three ways of solving the particular problem that I created this issue for:

• when a client is instantiated, what we currently get is a Pid. when {{use_native_encoding(Pid, Use)}} is called, we store a per-Pid entry in the process dictionary that gets used whenever {{riakc_ts:put}} and {{riakc_ts:query}} are called, to decide behind the scenes which encoding scheme to use. This is the approach I've taken, because it is the smallest deviation from what we currently have implemented. However it still requires a process-dictionary lookup every time {{put}} and {{query}} are called, which is not ideal
• when a client is instantiated, what is returned is an object that contains the Pid, as well as metadata about that Pid, like the desired encoding type _This is more optimal than a dictionary lookup, but means that the exported interface to {{riakc_ts}} would fundamentally change. This could break somebody's erlang code that uses the returned Pid directly rather than using the return value of {{riakc_pb_socket:startlink/2}} as an opaque type
• we could get rid of the concept of a per-client encoding altogether, and have variants of {{put}} and {{query}} that allow different encodings.
  This would be the most performant way of doing it, is non-invasive in terms of changing the {{riakc}} interface, but gives the freedom (and therefore puts the onus) of specifying an encoding on the user

(Note: the latter could also be implemented in addition to either of the first two options)

Thoughts?

_[posted via JIRA by Erik Leitch]_

[Basho-JIRA]

In a set of PRs that I'm about to unleash on the world, I've conceptually reworked how T2B message encoding is handled, from a separate protocol that is imposed on top of the same set of messages used for PB encoding, to a protocol that is linked to to a separate set of messages. In short, PB messages use PB-encoding, and T2B messages use T2B-encoding.

What this means is that clients can now do whatever they want -- they can happily send interleaved PB and T2B messages if they want to, for example (and also that sending the encoding toggle message is no longer necessary).

So there are now (at least) three ways of solving the particular problem that I created this issue for:

• when a client is instantiated, what we currently get is a Pid. when {{use_native_encoding(Pid, Use)}} is called, we store a per-Pid entry in the process dictionary that gets used whenever {{riakc_ts:put}} and {{riakc_ts:query}} are called, to decide behind the scenes which encoding scheme to use. This is the approach I've taken, because it is the smallest deviation from what we currently have implemented. However it still requires a process-dictionary lookup every time {{put}} and {{query}} are called, which is not ideal
• when a client is instantiated, what is returned is an object that contains the Pid, as well as metadata about that Pid, like the desired encoding type _This is more optimal than a dictionary lookup, but means that the exported interface to {{riakc_ts}} would fundamentally change. This could break somebody's erlang code that uses the returned Pid directly rather than using the return value of {{riakc_pb_socket:startlink/2}} as an opaque type
• we could get rid of the concept of a per-client encoding altogether, and have variants of {{put}} and {{query}} that allow different encodings.
  This would be the most performant way of doing it, and is non-invasive in terms of changing the {{riakc}} interface, but gives the freedom (and therefore puts the onus) of specifying an encoding on the user

(Note: the latter could also be implemented in addition to either of the first two options)

Thoughts?

_[posted via JIRA by Erik Leitch]_

[Basho-JIRA]

I'm using the "behind-the-scenes" method in the Python client and default to using TTB encoding. The user can override this by passing options to the client when it's being constructed, but I doubt anyone will.

_[posted via JIRA by Luke Bakken]_

[Basho-JIRA]

Closing since the implementation uses the proplist option {{use_ttb}} rather than this method.

_[posted via JIRA by Luke Bakken]_