Hello World: Software Development

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 ...

For years now, I've seen two sides to the discussion of how to handle enumeration data, especially in normalized databases.  In most cases, enumerations need to be explicitly defined and understood by code for decision-making.  Everyone seems to understand and agree on this point.  This is when teh discussion diverges. Side One When that happens, may people make the argument that enumerations do not need to be in the database in a normalized table because the data can just be represented as a string or number/ordinal in the database, the same way it is represented in the code.  This saves additional database work up front and allows database tools like hibernate to work more simply. Side Two The other side of the discussion says that enumerations represent defined data that sometimes warrants refactoring and migrations, and accomplishing said changes is much easier when data is normalized.  Additionally, the other side says that we should be able to query ...

After I generated my entities and got all the basic functionality of a JHipster application running, I started working on a multi-table join query that I want to use for reporting.  I don't want to query individual records and then aggregate my query results into a report using java; this is inefficient, and a single query can do all of the work for me, keeping the database doing what it does best.  So I wrote the query, and I then had to figure out how best to use this query in the JHipster framework. The best option seems to be using JPA's native SQL API and mapping results to a custom data object.  I can inject an EntityManager, and that allows me to call createNativeQuery().  I can then call setParameter() for each parameter needed by referencing my parameters by name like this: Query select foo from bar where some_column = :columnParam API nativeQuery.setParameter("columnParam", <valueToUse>) So far, so good.  When I make this call at runt...

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...

As I continue to play with JHipster, I've run into an issue of getting liquibase to work with my development database.  Out of the box, I decided to use in-memory H2 as a dev database and MySQL in production.  This seemed reasonable when I started, but I quickly discovered that if I try to add a change set to load data into my database using liquibase, it doesn't work with in-memory H2.  It looks like liquibase is only going to work with more persistent databases.

I've started working on a local project with JHipster, and as I generated the project, I noticed that the log output gave me many warnings like this: WARN deprecated swagger-ui@2.2.10: No longer maintained, please upgrade to swagger-ui@3 Swagger itself is just another tool that lets us more easily access and describe REST APIs while testing, and it is not really meant for production use.  No big deal in and of itself.  The bigger deal is that it seems like even though I am using the latest version of JHipster, the dependencies being consumed by that version themselves are already going out of date.  I haven't dug into the documentation on JHipster yet to see whether there are issues or concerns about manually updating these dependencies myself -- examples might include dependency version requirements, dependency conflicts, etc.  Still, I pause a bit with this as a production tool because unlike a standard library, JHipster is more of a generator and bootstrapper/...

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 h...