Comments - Tips on Converting to Galera

6 months, 1 week ago Olaf Schlüter

Thank you for your reply.

This internet example illustrates how JPA works with @Embedded objects in @Elementcollection members of entities:

As you can see, both the phone numbers and address tables lack a primary key and it isn't even guaranteed that the rows in those tables are unique.

I have a similar structure in my project with a collection of documents consisting of one or more documents, each document being described by title, short summary and version. JPA creates a table for the document collections and a table for the documents, where every document in the documents table refers to the document collection in the document_collection table it belongs to by a foreign key relationship. The document collection table has a PK, the documents table has not. I cannot think of a more efficient setup of such a data structure and obviously no primary key is needed for the documents table here. A document may appear in more than one document collection. There may be even duplettes of documents within one collection, which would create identical rows within the document table.

JPA treats those embedded entities as part of the entity they belong to. It's like a table as a column of another table. One can create such entities in any OOP language easily, whereas separate tables are needed in any relational database to represent them.

To make this work with Galera cluster reliably, do I need to sneak an auto-generated id into the documents table (which I could do easily in the table setup sql script used by flyway)?

Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.