cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Michallat <>
Subject Re: object mapping and keyspace in @UDT and @Table
Date Mon, 10 Nov 2014 13:42:27 GMT
Hi Reik,

This is the mailing list for the Cassandra developers. The Java driver has
a dedicated list, which is located at!forum/java-driver-user

I'm going to answer your question there.


Olivier Michallat

Driver & tools engineer, DataStax

On Mon, Nov 10, 2014 at 12:06 PM, Reik Schatz <> wrote:

> I am using the new object mapping API for the first time with a 2.1
> cluster. Recently I hit a problem when using different keyspace names,
> i.e. the keyspace in our integration test environment was called
> differently from the keyspace we use in our staging environment.
> The problem is that the keyspace in the object mapping API is
> specified at compile time using the keyspace attribute in the @UDT or
> @Table annotation of the annotated bean. This sort of makes it less
> flexible as you cannot re-use the bean in different keyspaces, so I
> was wondering why the API has been designed like this - I guess there
> is a reason?
> Looking at MappingManager.getUDTMapper or MappingManager.getMapper,
> access to a session instance exists, which could have been used to
> fetch the keyspace name instead or as a fallback. Of course the
> session could not be connected to a keyspace, but the user can be told
> that with a nice Exception.
> How do you feel about adding a fallback like this:
> - keyspace defined in @UDT or @Table = use it (todays behaviour)
> - otherwise if keyspace is empty, use session.getLoggedKeyspace
> - if getLoggedKeyspace is empty = improved Exception
> Currently you get a NullpointerException in UDTMapper or Mapper if the
> keyspace doesn't exist. If you guys agree, I would like to write a
> patch.
> Cheers,
> Reik

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message