Cannot query table with UDT in different keyspace to that of the session

Description

Using the LINQ Table I can insert rows into different keyspaces by overriding the session's keyspace with the constructor new Table<T>(session, mappingConfiguration, table, keyspace). If my table contains a UDT I can insert rows without issue, however I get the following exception when I try to query them.

I've created a unit test that illustrates the problem.

Querying data in CQL Shell shows rows were inserted as expected:

Full error details

Environment

None

Activity

Show:
Jorge Bay Gondra
March 8, 2016, 7:52 PM

The driver expects 1 class/struct per different Udt.
In your case, there are 2 different user-defined types in 2 different keyspaces, you should have 2 classes and 2 definitions.

In your case:

Alex Furmanski
March 9, 2016, 9:41 PM
Edited

Surely then the driver should not let me insert the data in the first place? The current behaviour is inconsistent and make UDTs unpredictable and difficult to work with. I have worked around this issue for the time being by abandoning UDTs altogether as the driver support does not seem complete.

Jorge Bay Gondra
March 9, 2016, 11:33 PM
Edited

I'm sorry that you feel that way.

The current functionality allows you to define a mapping of a CLR type per CQL type. A CQL type with the same creation syntax in 2 different keyspaces are 2 different data objects.

We could add the functionality to allow a mapping for any given CQL type with that name (like in this case) but that could bring more obscure errors inn case the schema of the 2 CQL types is not the same or 1 gets altered and the other does not.
We could warn or prevent the user to define a mapping for the same type to different CQL types, but this is not the case.

I've created to allow to define UDT mappings without switching keyspaces, in your case it would be:

Alex Furmanski
March 12, 2016, 2:59 AM

Jorge: sorry for the tone of my previous comment. It's easy to forget sometimes the effort that goes in to open source projects such as this, and I do appreciate your hard work.

Not a Problem

Assignee

Unassigned

Reporter

Alex Furmanski

Labels

None

Reproduced in

None

PM Priority

None

Fix versions

None

External issue ID

None

Doc Impact

None

Reviewer

None

Pull Request

None

Epic Link

None

Sprint

None

Pull Requests

None

Size

None

Components

Affects versions

Priority

Major