object mapping and keyspace in @UDT and @Table

[Reik Schatz <re...@gmail.com>]

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

Re: object mapping and keyspace in @UDT and @Table

[Olivier Michallat <ol...@datastax.com>]

Hi Reik,

This is the mailing list for the Cassandra developers. The Java driver has
a dedicated list, which is located at
https://groups.google.com/a/lists.datastax.com/forum/#!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 <re...@gmail.com> 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
>