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 <reik.sch...@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 >
