Skip to main content

First thoughts on working with JHipster

I'm working through a sample application with JHipster, and so far, I like it.  The approach and instructions seem straight forward, and the ability to generate domain objects and associated code using jdl is nice.  I've also looked at generating the domain objects for different kinds of databases, and the results are intriguing.  When generating code for mysql (a relational database), we see lombok doing a lot of work to generate boilerplate.  This is not the case if we generate code for mongo (a document-oriented no-sql database).  For mongo, JHipster manually generates getters, setters, equals, hashcode, and even some other builder-type methods.  The important thing here for me is not so much the use of various tools, but more the basic fact that the resulting generated code is fundamentally different.

I tend to work in Windows most of the time, and this has become a problem for trying to run databases and other useful tools/images in docker.  I have Windows 10, but not the Pro edition (maybe I should just spring for it?), and docker does not work unless you have the Pro edition.  I've noticed that there is now built-in access to bash for windows, so I am considering that as an option for trying to get docker installed on Windows.  Until then, I'm running all of my docker images on my mbp, and I'm just connecting the dev deployed Windows builds to the databases running on the mbp to keep going so that I don't get bogged down.

JHipster generates application.yml files (both dev and prod!) for spring boot, and IntelliJ easily finds and helps auto-complete changes to the properties necessary to connect to the docker images on my mbp, which is very nice.


Popular posts from this blog

Spring Security - Authority vs Role

I have spent a lot of time recently trying to understand the difference between Authority and Role in Spring Security.  This is a brief review of what I found. When creating a UserDetailsService or overriding configure(AuthenticationManagerBuilder auth) in the security config class that extends WebSecurityConfigurerAdapter, I basically get complete control over what I populate inside of the UserDetails that is used/returned.  This is important because the UserDetails interface really only cares about how to return one thing: Collection<? extends GrantedAuthority> getAuthorities(); A GrantedAuthority just seems like a glorified String wrapper that names some thing.  The question is... what is that thing? This is where the subtle difference between Authority and Role comes into play. I think that Role is an older thought/construct that automatically gets plugged into Authority if we just create a user with a Role.  But completely forget about the code and classes for a mi

JHipster, Liquibase, MySQL, and initializing data, including booleans!

When generating a data model from JHipster JDL, we will often declare entities with Boolean fields.  I have so far abandoned H2 as a database because of liquibase issues, and both my dev and production databases will be MySQL.  This is relevant to the Boolean field desire there is a long history in software development of how to store Boolean data types in a SQL database whose standards classically do not support Boolean. In the current JHipster/Liquibase incarnation, tables in MySQL are generated for us, which is really nice.  The Boolean data types are stored as BIT  (1).  This is not a problem so far -- most developers seem to agree now that as a best practice, we should store values in databases as false = 0 and true = 1, and a BIT(1) is a great, simple way to do that. An issue arises when we try to use liquibase to set/update our database to the desired starting state.  For my project, I've chosen gradle instead of maven as a build tool, and gradle has a plugin for liquiba

SQL, Booleans, JPA, and Hibernate

For a long time, SQL and Booleans have not gotten along.  Standards for SQL never really addressed the need for boolean data -- it was assumed that some other data type could easily just step in and address this need.  The result was a lot of different data models for boolean values.  Here are some examples. TRUE or FALSE T or F Y or N 1 or 0 <any value> vs NULL The internet shows the debate has gone on , even as SQL standards have changed .  Coming from a professional background with Oracle, I struggled with this across my teams because everyone had a different opinion, which led to a lot of time wasted due to debate. This said, I appreciate working with native queries in hibernate's JPA implementation against MySQL.  MySQL supports a BIT data type I recently discussed .  When we represent data in MySQL with BIT and restrict the length to just 1 (ie 1 bit), Hibernate JPA magically knows to query and return this data as a Boolean in the data returned by getResul