Understanding Entity Relationship Mapping, Part 2: Annotating Entity Relationships

In Understanding Entity Relationship Mapping, Part 1: The basic concepts I glazed over some of the basic concepts that would be encountered when dealing with establishing relationships between Entities. This post would take a look at how to use Annotations to specify these relationships.

The relationships that would be annotated are the four types that you have in relational data model:

1. One-To-One annotated with @OneToOne
2. Many-To-One annotated with @ManyToOne
3. One-To-Many annotated with @OneToMany
4. Many-To-Many annotated with @ManyToMany

If concepts like Cardinality, Direction of Relationship, Cascades, Owning side and Inverse side of Entity relationship is new to you, then it is would be good to first read Understanding Entity Relationship Mapping, Part 1: The basic concepts

The relationship would be classified into two: Single Valued Mappings and Collection Valued Mappings. It is worth stating that the examples were written with Hibernate's implementation of JPA in mind, but would work with any other standard implementation of JPA 2, as no Hibernate specific annotation is included.

So let us begin.

Understanding Entity Relationship Mapping, Part 1: The basic concepts

It is possible to create a working functionality of a system using tools/technologies that is not fully understood, as long as some minimal knowledge is present: what things are, where to find them, and how to wire them together in other to get them to work. And thank heavens, with the help of search engines, you can easily scour the web for solutions to anomalies that pops up, due to the lack of complete grasp of the tool being used. But without a more in-depth knowledge, or at least a grasp of the basic fundamental concepts, it would become difficult to accomplish more complex or customized tasks, troubleshoot issues and general extend beyond the basic functionality.

This was how I was treating mapping entity relationships in the ORM domain, via Hibernate's implementation of JPA, for a time now. I had the basic knowledge of relational database modelling, how relationships are constructed using primary keys and foreign keys in SQL, how data can be fetched from tables that are related using joins: basic knowledge that has its roots solely in the relational way of looking at databases. So I was able to annotate up entities and set up relationships. Get stuff persisted and maybe updated. But I kept running into minor errors now and then, configuration issues, minor oversights etc.

One of the areas these annoyances kept popping up was in how to describe relationships between entities. After I have had enough of head banging against the wall, I decided to just take a step back to understand, at least, a little bit more, the tool I am using and what I was dealing with here.

This blog post is the outcome of that stepping back. It has two parts to it. This post, which describes some basic terminologies that you would come across while working with most JPA implementations and the second: Understanding Entity Relationship Mapping, Part 2: Annotating Entity Relationships, which shows how entity relationships are annotated.

So here we go:

How To Use .call(), .apply() and .bind() In Javascript

Back in March I wrote a post "Understanding Constructor Functions in Javascript and This keyword" in which, while explaining the concept of this in Javascript, I stated that it is impossible to tell what the this keyword references by just looking at the function definition. You only get to decide or know what the this keyword refers to, by the way the function is called. Call the function one way, and have this refer to one object, call it another way and you can have it refer to a totally different object. Showing that in Javascript, this is a context-indicator.

I mentioned that normal calling of a function (i.e. have a function fx, call it via fx()) and calling with the new keyword i.e. (new fx()) are some of the various ways to call a Javascript function and have the this keyword switch context.

There are 3 other ways a Javascript function can be called with the ability to determine what this keyword references. call, apply and bind. To be technically specific: Function.prototype.call, Function.prototype.apply, and Function.prototype.bind.

Javascript is not Java. Deal with it

There are different paradigms when it comes to programming languages. With each paradigm, you have different and unique methods and concepts that are used in the task of computation and getting the computer to do what you want. Sometimes these concepts share similarities; sometimes they go about their task in totally different ways. The merit of a paradigm is thus judged against the backdrop of the problem it is being used to solve and whether it is the best fit.

It would then be totally silly and dense to put a language down solely on the fact that it incorporates a different paradigm when compared to a language you are familiar with. Most of the bashing I see targeted at Javascript is largely due to this: coming from a different programming paradigm and getting miffed when different ways of doing things are encountered in the Javascript land.

At the risk of being wrong and committing fallacy of hasty generalization, I would say Java developers are most guilty of this (maybe it has to do with the misleading "Java" in Javascript? :p)

I say this, because from personal experience, (which I know is limited) I do not get the same close mindedness from the Python, Ruby and C# devs that I know.(This explains the title of the post I guess :p)

Maybe it is that difficult to come to terms that Javascript is a prototype based object oriented language and not a class based language?

Consequences of this close mindedness towards Javascript, thus lead to hacks and practices that try to bend and mould Javascript into something which it is not. I most of the time find this to be quite uneducated.

Coming from a Javascript-first background, before Java, I guess made it quite hard for me to have this kind of narrow mindedness and priggish attitude? I guess this helps to easily appreciate the unique ways of doing things in both languages. I like to think that this makes a better developer, as it is quite interesting to see how different ideas are implemented across languages and borrow from them in situation, when it is germane.

So when (if) I want to learn Haskell, I won’t go about complaining over how it has so many concepts; tricky and odd concepts and how it does things different when compared to say Javascript. And I wont try to write Javascript in Haskell.

And by the way, Javascript is not the only language that has its good parts. Every language does, Java, C++ inclusive :)

Fixing org.springframework.http.converter.HttpMessageNotWritableException Error

A couple of days back, I ran into an interesting error while retrieving persisted entities as JSON  in SpringMVC:

[Request processing failed; nested exception is org.springframework.http.converter.HttpMessageNotWritableException: Could not write JSON: Infinite recursion (StackOverflowError)...

I had to do some poking around and reading up on documentation to figure out how to fix it.

As it turned out, the fix wasn't that complex and the culprit was Jackson: the Java-JSON processor being used to transform the retrieved Java entity to a JSON representation.

The error occurs when you try to retrieve an entity that has a bi-directional @OneToMany relationship with another entity.

Enum in Java.

Let us assume you have the need for some constants in your application; say the three primary colors: Red, Green, Blue. You could create a class specifically for holding the constants thus:

class PrimaryColorsStatic {
        public static final String RED = "red";
        public static final String GREEN = "green";
        public static final String BLUE = "blue";
}

and any of these can be used: PrimaryColorsStatic.RED or PrimaryColorsStatic.GREEN or PrimaryColorsStatic.BLUE

This would work, but it is very limited. Let say you want to hold, apart from the name, the hex code and rgb code of the color as part of the constant? How would this be done with the mechanism above? Whatever way you find to implement this would feel forced as static variables of classes were not designed to help fulfil such use cases.

Enum in Java provides a more robust mechanism for dealing with constant values in your application.

Enum can be formally defined as a special data type that enables for a variable to be a set of predefined constants.

The basic syntax is simple. The primary color example can be represented as an Enum with the following code:

public enum PrimaryColorsEnum {
     RED, GREEN, BLUE
}

[this means that the file would be saved as PrimaryColorsEnum.java]

and an example of accessing it would be:

public main void() {
    PrimaryColorsEnum RedHolder = PrimaryColorsEnum.RED;
    System.out.println(RedHolder);
}

This would print red to the console as a string.

Just knowing the above syntax and when to use it could get you by with Enum, but you have hardly scratched the surface with just that.

To fully appreciate Enums, let us take a step back and see if we can grok the concept in a more detailed level.

Getting Started with Git...Introduction to the basic work flow

This is a very fluid and informal guide to some of the git commands you would come across with a relatively moderate level of frequency as you work with Git. It covers the basics of the git work flow.

And by the way, this is not a true life story...

So yes! First day at work! Congrats! You managed to pass through the technical assessments and various stages of interviews (you did a swell job selling yourself and how awesome you are innit?) Phew! Now it’s the time to come in and start doing all those stuffs you profess you can do! Yes!

After the round of introduction to other folks in the company and your co-developers, you are "introduced" to your work station: All set up nicely; with the right number of monitors just as you like it. Your favourite IDE is already installed too! Cool!

Your new company uses version control to manage collaborative development. Well if they don't am sure you won't be there wanting to work for them...right? Yes, right.

Done with all the introduction and already taken your seat. Your team-lead tells you to get comfortable and that you would be receiving instructions in your email in a couple of minutes regarding getting started, things to configure, account credentials blah blah, etc. etc.

And true to his words, in a couple of minutes your Github username and password arrives in your inbox accompanied by the repository URL you would be working with. Also with those came some additional jargon about common practices, style guides, team practices, schedules etc.

You take about 30 minutes to get acquainted with the new materials you have just received...

...done, cool stuffs in general but now It’s time to set up the project you would be working on!

Even though no one says it is, you feel this innocuous task of setting up your working machine, is somewhat of a test. And you can literally feel eyes behind your back watching to see how you would proceed. But before starting to hyper venting you do yourself a huge favour -- tell yourself  “c'mon, don’t be that paranoid”.

You take a deep breathe and quickly proceeded to doing what needs to be done.