Java UUID or QueryBuilder uuid - java

I'm using Datastax Java driver to perform basic insert statement in Cassandra database. My primary key column is uuid type. From what I see in official documentation, recommended way to call uuid() function in Cassandra is to use QueryBuilder#uuid() method. However, is it safe to use java util's UUID.randomUUID() too, since my types are colliding (QueryBuilder.uuid() returns Object while UUID.randomUUID() returns UUID)?

UUID.randomUUID() creates type-4 UUID and it is safe to use.
Infact, datastax UUID utility class com.datastax.driver.core.utils.UUIDs has a method named random(), which is just a convenience for UUID.randomUUID()

If you are using the generated UUID for ordering (clustering key), please use QueryBuilder#uuid(). This is because Cassandra has a different implementation. The Java UUID ordering is different.
If you are using it as any other key, it doesn't matter.
Hope it helps!

Related

Java Cassandra QueryBuilder now() for timestamp fields

Working with the datastax Cassandra QueryBuilder, is there any way to insert now() into a timestamp column?
The current implementation does not have a dateOf or toUnixTimestamp function. The now()function itself returns timeuuid which is incompatible with timestamp.
This may depend on the version of the driver...
For driver 3.x, there is a generic fcall method that allows you to call any function, something like this (didn't check, but you get an idea):
.fcall("toTimestamp", now())
For driver 4.x, there is similar function call. You even have the possibility to use raw code snippets.

CockroachDB SERIAL field not working with JPA IDENTITY Strategy

I'm migrating an app to use CockroachDB and we are using the GeneratedValue mapping in Java with SERIAL type columns to manage primary keys.
id SERIAL PRIMARY KEY -- SQL
#Id
#GeneratedValue(strategy = GenerationType.IDENTITY) -- Java JPA
We are getting the following error
ERROR: currval(): relation "scm_supply_centers_id_seq" does not exist
We dug a little and found out that it's because of PostgreSQL Dialect trying to get the last id inserted in as you can see in this link
PostgreSQL81IdentityColumnSupport
How can I find a workaround for this issue?
The SERIAL type is not backed by a sequence in CockroachDB. In order to use a SEQUENCE you need to explicitly create it and use the nextval() function as the DEFAULT value for the column. For example,
CREATE SEQUENCE customer_seq;
CREATE TABLE customer_list (
id INT PRIMARY KEY DEFAULT nextval('customer_seq'),
customer string,
address string
);
Note that there are performance implications to using SEQUENCE vs SERIAL due to the additional synchronization and communication requirements. See https://www.cockroachlabs.com/docs/stable/create-sequence.html for more details.
The above doesn't exactly answer your question, though. I don't know how you would use an explicit sequence from Hibernate.

Conversion String to UUID in Postgres and Java

I need to convert String ( text ) to UUID ( Postgres ) and keep the same sorting like for a String. Is it possible? I saw the UUID base on the time, so maybe it's not possible?
In PostgresSQL's SQL grammar
Using
concat(UUID,'')
returns a text result. Using
uuid(text)
returns a UUID result.
In PostgreSQL, apart from using uuid(), it's also possible to specify the type explicitly like ::uuid:
with myconst (__ef_filter__id_0, __filter_workitemid_0, __filter_projectid_1, __id_2) as (
values ( 'fcb8284c-1bd4-4d50-b5df-09a091b01d8c'::uuid, '9e4b70a7-c222-47dd-87cb-fbbaaf396ccd'::uuid, uuid('2b10c0a5-e35d-425d-a71a-9e473924ac4c'), uuid('3fa85f64-5717-4562-b3fc-2c963f66afa6')) )
select ...
There is a class in JDK dedicated to the management of UUIDs, called java.util.UUID. There's a static method fromString in it that should fit your goal. As far as I can see, you can use instances of UUID in JDBC insert statements.
At oVirt open source project, we use the PostgreSQL uuid type to store our Primary keys and Foreign keys.
We have build a wrapper called Guid that uses the java.util.UUID class to hold the read data from the DB.
When retrieving a ResultSet (we use spring-jdbc) we use the getString method in order to get the UUID value as String, and then use the fromString method of java.util.UUID.
You can git clone our project and look at ovirt-engine/backend/manager/modules/dal (our data access layer) project for more information.

How should I save UUID with JPA?

How should I work with UUID and JPA?
Should I assign the random UUID value to a String field in my class? Or should I have a field with type UUID and do something else to it when I want to map it to a column?
That depends on the database.
There are databases such as H2, MSSQL and PostgreSQL that support a uniqueidentifer type.
For these types you can extend the provided Dialect (i.e - PostgreSQLDialect) and add handling of the new type.
I implemented something like that, based on the following post , for both MSSQL and Postgresql.
For databases that do not support a uniqueidentifier/UUID type, you should use String.
This means that you should also ask yourself if your application must support multiple database vendors, or if you can stick with a single vendor (and then select the first option, if applicable).

migrating a hibernate class from a sequence based integer primary key to a GUID primary key while retaining the old keys for backward compatibility?

What strategy is good for migrating a hibernate class from a sequence based integer primary key to a GUID primary key while retaining the old keys for backward compatibility?
We have an extensive class hierarchy (using the joined-subclass model) where the base class has a Long primary key generated from a sequence in the DB.
We are working on transitioning to a GUID primary key, but wish to retain the old primary key (both in old and newly created content) for legacy apps. While the implementation seems fairly straightforward (change the primary key to GUID, add an interceptor to populate the content ID on new content), what pitfalls might I want to watch out for?
Are you sure you want to do this?
I understand wanting GUIDs, but do you really want them to be your database PKs. Some informal testing I did showed that there was about a 10-15% hit in using a GUID PK for joins / searches vs an integer PK. I would suggest you try out some tests with GUIDs on your current population and see what the performance hit is. It may be better to just add a uniquely indexed GUID column to your tables and leave the PKs as they are.
I can't think of a pretty solution but,
I would create another field to hold the GUIDs and auto generate IDs for any records that currently exist and go from there. It will smell a bit but it's better than trying to store incompatible types in the same field if you ask me.
Stupid bugs like "we know that PK is GUID so it's length is always that many"...

Categories