Generator-jhipster: [FEATURE] Allow UUID primary keys

[bytor99999]

Overview of the issue

Currently all Entities generate by JHipster makes the @Id PK auto-generated and Long. However, I think the majority of people are now using UUIDs for Primary Keys.

Motivation for or Use Case

So right now we are creating an admin application for our web site/app. I think this is a very common type of CRUD app someone might use JHipster for, as we need something that is quick to develop. But will mostly be coming with their own database already designed. (Also security, but that is another ticket).

So what happens if you end up creating a new entity, entering all the database fields etc. Then after everything is generated having to go through and change the Entity and Repository classes. And sometimes might need to go into the UI portions (Usually less often)

JHipster Version(s)

Not sure if this matters. We are further behind on our JHipster version. I think 1.5. because every time we upgrade requires a lot of work to redo all the security objects and UI back to our application's Security entity objects (No need to go into more detail, we have about 5-6 tables to make up our users and roles and privileges.)

JHipster configuration, a .yo-rc.json file generated in the root folder

N/A

Entity configuration(s) entityName.json files generated in the .jhipster directory

N/A, Any Entity

Browsers and Operating System

IE 3. Just kidding. All browsers

Reproduce the error

N/A

Related issues

Not that I have seen

Suggest a Fix

Maybe when generating the Entity through yo, one of the questions be type for the ID. This will help for UUIDs, but also the rare very rare case where we might make it a String for the UUID, because of database being used.

Thanks

Mark Spritzler

[bytor99999]

Since I have been having another issue and started looking at code in GitHub.

if (databaseType == 'sql') { %>
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;<% } %><% if (databaseType == 'mongodb') { %>
    @Id
    private String id;<% } %><% if (databaseType == 'cassandra') { %>
    @PartitionKey
    private UUID id;<% } %>

And in the json file be able to have a property. say

entity.json allow I think at the top level like where "dto", "service" properties are
{"keyType":"String|UUID|Long", ...}

I think that alone and put in above would work. I mean you already have the private TYPE id; already there for all three types.

Thanks

Mark S

[amitjindal]

I would also request this functionality. Having UUIDs gives additional security (not guessable) and allows client side generation, ability to have disconnected databases (for later reconciling).
Currently I have a hack to do a post generation fix as a module but its less than optimum and I think this should be a core feature.

[deepu105]

I dont think this is a very generic use case and not sure if its worth adding as an option. Ill let @jdubois take the call.
@amitjindal may be you publish your module so that other can use it as well

[jdubois]

I'm guessing you only talk of SQL databases, because we do have UUID for MongoDB and Cassandra.
If you want to use an UUID as a PK for MySQL, then your performance is going to be really, really bad. I'll let you search the Internet for that :-)
So for me it's a bad idea, and I don't think we should have this kind of option available.

[deepu105]

thats a no from @jdubois I guess so @amitjindal your module might be a good option for @bytor99999

[bytor99999]

I understand, but using a Sequence Long as a PK is also a really bad idea
in distributed systems. If I have a clustered database, a Long Sequence
will cause duplicate PK generated on these databases. Also, if you look
around and lots of applications today, people are no longer using Long
Sequences and are now more using UUIDs as PKs.

Thanks

Mark

On Wed, Mar 2, 2016 at 11:21 PM, Julien Dubois [email protected]
wrote:

I'm guessing you only talk of SQL databases, because we do have UUID for
MongoDB and Cassandra.
If you want to use an UUID as a PK for MySQL, then your performance is
going to be really, really bad. I'll let you search the Internet for that
:-)
So for me it's a bad idea, and I don't think we should have this kind of
option available.

—
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/3060#issuecomment-191624249
.

[jdubois]

Yes, and we do use UUID on distributed databases, like Cassandra.
And MySQL is not a distributed database.

[bytor99999]

Unfortunately, I inherited this database. I prefer Postgres over MYSql. But even prefer Mongo, Neo4J and Cassandra over RDBMS. Wish I could be all greenfield on this. Anyway, I can customize the generated entity and repositories. I'm only building a small admin app here for our real app. Meaning not for our users but for the few business people that need to add user records and fix a few pieces of data in the database.

Thanks

On Mar 3, 2016, at 2:16 AM, Deepu K Sasidharan [email protected] wrote:

thats a no from @jdubois I guess so @amitjindal your module might be a good option for @bytor99999

—
Reply to this email directly or view it on GitHub.

[amitjindal]

Ok. I will try to clean it up if possible. I have only tested with some combinations so not sure if it will work properly with all variations of options in JHipster and this is my first take too.

[lsgpimentel]

@jdubois,
Can you, please, reconsider that?

I agree that having the option to use an UUID as key is a good idea. Of course, the performance in all RDBMS are worse for UUID's than sequential integers.

PostgreSQL, for example, have a much better performance for UUID's than MySQL. Anyway, the performance is a clear disadvantage, we're not discussing that. Other advantages should be pointed:

• not guessable, like already pointed. (This is what I need mostly now)
• can be generated offline
• unique across every table, DB and server

Besides that, IMHO, UUID as a type, even if it's not used as PK, should be provided, like it's provided for Cassandra.

[steelcoder]

Hi everyone, I think UUID should be supported for relational databases (maybe with a performance warning for MySQL users). The main motivation for us is to prevent scraping of our database (non disclosure). For example, with sequential id, a scrapper can scan all entities with a for loop!

@amitjindal : can you publish your module? maybe the community could enjoy and contribute on such a feature?

Thx.

[jdubois]

The ID is a technical key, it shouldn't be used for this. For instance, it shouldn't change, so it should be safe to share, which is typically not your case.
What you need is a business key, which is what we do for the user login, for the activation key, and for the password reset key.

[amitjindal]

Just got this notification. Sorry for delayed response. Let me clean that up and I will publish. I am not as good in these generators so probably will need help.

[amitjindal]

@steelcoder @bytor99999 @deepu105
Sorry for the long delay. I uploaded the code after cleanup. Its not extensively tested but we have been using this internally for almost 10 months with minimal problems. See here: https://github.com/amitjindal/generator-jhipster-postgresuuid-converter

In next few days I will polish this and submit this to NPM repository.