Persisting an entity graph fails with "Unable to add column with ..." about datanucleus-cassandra HOT 9 CLOSED

I forgot to mention. To run the tests a running Cassandra instance with a "test" keyspace is required. Additional information about the configuration can be found in the properties.xml file of the corresponding project. The data model used can be found in the "test-model" submodule of "integration-tests" module.

from datanucleus-cassandra.

Hi @andyjefferson, is there any chance to get this issue addressed? Do you need additional information? Thank you in advance.

from datanucleus-cassandra.

This issue can be addressed in the following ways

1. You get the code, work out the problem, and contribute a pull request. Aka open source route
2. You pay for support, and convert your testcase to use the datanucleus template, showing just the test that has a problem.
3. You wait and one day someone may have time, but then unlikely to be soon.

from datanucleus-cassandra.

Ok. I take 1:)

from datanucleus-cassandra.

More than likely due to your misuse of mapping for Cassandra. Cassandra does not do JOINs, and consequently DataNucleus maps any relation field as a COLUMN in the table of the class that the field is for. Consequently if you have a Set field, you get a COLUMN in the TABLE of the class that will hold multiple PK values (as an array). This means that when someone wants to retrieve an object and a multi-valued field we can retrieve the id of the related objects easily. So maybe you have multiple fields in a class that all want to use the same COLUMN in that table?

But then JPA was designed for RDBMS ONLY (and its annotations and query language show that) so to be expected. I have no plans at all to support persisting a column over in the table of a related class, since it makes little sense in the context of Cassandra; people can contribute that as an option if they really want it

from datanucleus-cassandra.

As previous message, I see no problem. This is how relations are handled with non-RDBMS datastores. If you want to develop support for holding the FK over in the element then please provide a pull request and this can be reopened. Thx

from datanucleus-cassandra.

Hi @andyjefferson, sorry for the belated answer. Actually you're right in the sense that data in a column based database should/have to be organized differently as in an RDBMS. While working on a project (maybe you've seen it on my github profile) which goal is to uniform the implementation of integration tests for JPA based code regardless the used db type (and jpa provider), I've tried (until recently) to reuse the same domain model while using different db implementation. This approach has worked with mongodb, it still works with neo4j, but it fails with cassandra and will definitely fail with key value stores. This was my though fault.

from datanucleus-cassandra.

Using multiple orm.xml is the logical way of applying the differences in mapping between relational and non-relational datastores, hence keeping schema info out of the classes (annotations).

The handling for checking for attempted reuse of columns is present in DataNucleus generic code, so used by ALL non-RDBMS datastores, and so MongoDB, Neo4j, Cassandra and others would get such a problem with the same input mapping.

from datanucleus-cassandra.

In my last sentence from my last comment I should have been more precise by saying, that it works with some JPA providers. Anyway, thank you for highlighting that. At least now I know at what to look at, when testing against DataNucleus.

from datanucleus-cassandra.