I generally dislike the machanism of using first contact point DC as local DC (/rack), but I wonder if this won't cause compatibility issues.

We could probably implement it by, in case dc name is empty, following mechanism:

• After session is connected check the DC of first contact point
• Then create new LBP with this DC set as local
• Swap it in session using something like this:

let handle = session.get_default_execution_profile_handle().clone();
let new_profile = handle.pointee_to_builder().load_balancing_policy(...).build();
handle.map_to_another_profile(new_profile);

I'm not sure preserving this mechanism is worth introducing such trickery - probably not.

Wow! Is it going to be the first time when profile mapping feature is actually useful (and used by anyone!) ?

As I said, I'm not convinced we should do this - actually, I'm more and more convinced that we shouldn't. So unfortunately it won't :(

How can we make a profile contain a load balancing policy? This is unclear to me from this docstring; is it clear from some other documentation?

cpp-rust-driver's session wrapper additionally holds a map of execution profiles, indexed by their custom names. You can firstly construct a profile, and provide custom options to it, and then pass it to CassCluster via cass_cluster_set_execution_profile with a name chosen for this profile.

Then, having multiple execution profiles defined and stored (each with unique name), you can "bind" one of your choice to some statement (see cass_statement_set_execution_profile), identifying the chosen profile by its name.

I know the mechanism you described, it was me who implemented it :)
The thing is, what does it mean that a profile contains a policy?

Ok, now I understand your question. So I studied the logic of cpp-driver, and it seems that this statement is true for cpp-driver. See: https://github.com/scylladb/cpp-driver/blob/master/src/request_processor.cpp#L196-L209

If user does not define an LBP for execution profile (i.e. exec profile does not CONTAIN lbp), then the session-wide LBP is used for this execution profile. So it means, we are inconsistent with cpp-driver. Consider following scenario:

• user sets session-wide LBP to dc aware: cass_cluster_set_load_balance_dc_aware(...)
• user creates some exeuction profile, but does not define LBP for it (let's call this exec profile "foo")
• now, when user executes a statement with a "foo" exec profile:
  • in cpp-driver, the session-wide DC-aware LBP is chosen for this statement execution
  • in cpp-rust-driver/rust-driver, the DefaultPolicy::default() is always chosen, no matter what session-wide LBP is set to

I believe that if we wanted to mimic this behaviour, then it's relatively easy to implement - no changes to rust-driver are required. The question is, however, whether we want to mimic such behaviour?

cc: @Lorak-mmk

I don't see anything wrong with such behavior. It actually seems quite useful - if you want to overwrite some things (e.g. CL and timeout) for some statements but don't want to overwrite everything. As this behavior is not buggy / footgun etc I see no reason to change it.

Actually I didn't even know that Rust Driver worked this way, I thought it behaved like cpp-driver in this regard :D

Opened a PR: #197

Actually I didn't even know that Rust Driver worked this way, I thought it behaved like cpp-driver in this regard :D

I can vaguely remember that we decided that overriding the global per-session execution only partly with per-statement exec profile is too complex (for a user). A profile should be considered a full configuration. If only some options are to be changed for a statement compared to the session globally, it's adviced to derive an execution profile - either by cloning the builder beforehand or by calling to_builder() on an existing profile.

Wow! Is it going to be the first time when profile mapping feature is actually useful (and used by anyone!) ?

Let's use C str literals, as they've been stabilised: https://doc.rust-lang.org/nightly/edition-guide/rust-2021/c-string-literals.html

Done. BTW, I cannot replace let empty_str = "\0".as_ptr() as *const i8; with let empty_str = c""; It results in a following ntest::timeout proc macro panic:

error: custom attribute panicked
   --> src/cluster.rs:884:5
    |
884 |     #[ntest::timeout(100)]
    |     ^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: message: Unrecognized literal: `c""`

It happens for any c str literal constructed outside of some other macro (e.g. assert_cass_error_eq).

Oh, maybe you should open an issue to ntest?