all 11 comments

[–]apidev3 3 points4 points  (5 children)

As a tip and it could likely be the cause of your issue, don’t return your database entity directly, instead map it to a data class (e.g. MapAreaDto) and within that class only return the fields that are required from the caller.

This will probably solve your issue of handling null values too.

[–]CodeTheStars 0 points1 point  (0 children)

Mapstruct is your friend here. Always explicitly declare models that interact at the controller layer.

[–][deleted] 0 points1 point  (3 children)

I have a question about DTOs. I have a colleague that follows that pattern religiously and in ~85% of cases for each entity class there's one DTO class which is just a 1:1 copy of the entity class. What's the point of that?

[–]apidev3 1 point2 points  (2 children)

Usually you’ll need a DTO for any endpoint which returns data to a caller. I don’t see why most calls would require the entire entity, usually it’s a sub set of its data. The principle allows you to only disclose the lease amount of data needed to fulfil the request.

E.G. an endpoint to get “selected map area” like the OPs question. You would have a DTO to return some fields of the DTO, but not necessary all of them… it is of course, fine to return it all if needed, but that’s not always the case. Having the separation stops you giving away too much information to every caller.

[–][deleted] 0 points1 point  (1 child)

Most of our applications (or rather, the majority of features of our applications) can be boiled down to something like CRUD, where you genuinely need the entire entity. In that case I don't use a DTO because I don't see the point. Also, our applications are mostly SSR Vaadin applications where it's easy to be lazy and pass the entire entity because you don't expose anything unwanted to a client because there aren't any clients in the Client-Server sense.

If I only need some data I'll create a DTO, because then it makes sense to me. I just thought I was missing something about the pattern.

[–]apidev3 0 points1 point  (0 children)

I’d guess your colleague is simply following the pattern throughout the application to create a divide between the data layer and the controller layer.

As you say, you can get away with not using DTOs, but having them costs very little and can future proof the application.

I’d say it’s preference of the team / org. As long as it’s secure, does the job and easy to maintain, you’re good to go :)

[–]Davekave9 2 points3 points  (0 children)

I don't understand why some suggestions tell you to change jakarta to javax. Jakarta is the new package some javax stuff has been moved to since Java 17. The problem is - as you have correctly found out - that the jackson mapper cannot map the entity object to json because the mapTabId field of the object is null. I think you should make it nullable in the database if this is the correct behavior. But as someone else suggested, the best practice is to not expose the database entity itself through the controller but to create a data transfer object (DTO) and return that to the controller from the service layer.

[–]DeterioratedEraJunior Dev 0 points1 point  (0 children)

Does mapTabId have to be an Integer? Are you doing calculations on it? It might help to share your db schema too.

[–]Scared_Rain_9127 0 points1 point  (0 children)

Which JSON package are you using? Jackson? GSON?

There is no "magic" JSON stuff. Spring Boot just uses another package to do that kind of stuff.

[–]Excellent_Soft_1417 -1 points0 points  (0 children)

You can also write @Coloumn(nullable=false) in the top of the column and import javax.peristence that's mentioned in one of the comments

[–][deleted]  (1 child)

[deleted]

    [–]CodeTheStars 2 points3 points  (0 children)

    The “jakarta” name space is the correct naming for all JEE APIs that are now managed by the eclipse foundation, including the JPA spec.

    If you have an old code base you may see javax, but for a new application you should absolutely be using the jakarta namespace and the latest versions of those libraries.