I'm using Spring boot 2.3, Spring Data REST, Spring HATEOAS, Hibernate.
Let's think to a simple use case like an user creating an invoice in a web client, or a inventory list for a warehouse. When the user submit the form, could be sent hundreds or rows and these rows can have links to other entities.
In the case of the invoice, for example, each row can have a product reference that will be passed to the sever as a link.
That link is translated by Spring into an entity using Repository. My point is that for every row, a query to get the product runs.
This means that everything will be really slow during insert (n+1 select problem).
Probably I missed somthing in the logic, but I didn't see concrete examples that focus on how to handle a big quantity of translations link -> entity.
Do you have any hint about it?
Is your point about many entities that will be created if linked entities will be returned to server? Hibernate (as well as spring) has lazy loading mechanism - https://blog.ippon.tech/boost-the-performance-of-your-spring-data-jpa-application/, so only necessary entities will be populated. Please, correct me if I miss understand your questions.
Related
I have a database and in that database there are many tables of data. I want to fetch the data from any one of those tables by entering a query from the front-end application. I'm not doing any manipulation to the data, doing just retrieving the data from database.
Also, mapping the data requires writing so many entity or POJO classes, so I don't want to map the data to any object. How can I achieve this?
In this case, assuming the mapping of tables if not relevant, you don't need to use JPA/Hibernate at all.
You can use an old, battle tested jdbc template that can execute a query of your choice (that you'll pass from client), will serialize the response to JSONObject and return it as a response in your controller.
The client side will be responsible to rendering the result.
You might also query the database metadata to obtain the information about column names, types, etc. so that the client side will also get this information and will be able to show the results in a more convenient / "advanced" way.
Beware of security implications, though. Basically it means that the client will be able to delete all the records from the database by a simple query and you won't be able to avoid it :)
One advantage of Document DBs like Couchbase is schemaless entities. It gives me freedom to add new attributes within the document without any schema change.
Using Couchbase JsonObject and JsonDocument my code remains generic to perform CRUD operations without any need to modify it whenever new attribute is added to the document. Refer this example where no Entities are created.
However if I follow the usual Spring Data approach of creating Entity classes, I do not take full advantage of this flexibility. I will end up in code change whenever I add new attribute into my document.
Is there a approach to have generic entity using Spring Data? Or Spring Data is not really suitable for schemaless DBs? Or is my understanding is incorrect?
I would argue the opposite is true.
One way or another if you introduce a new field you have to handle the existing data that doesn't have that field.
Either you update all your documents to include that field. That is what schema based stores basically force you to do.
Or you leave your store as it is and let your application handle that issue. With Spring Data you have some nice and obvious ways to handle that in a consistent fashion, e.g. by having a default value in the entity or handling that in a listener.
I have a order fulfillment application mostly made with Spring Data Rest and spring boot. I need to get every product, find them in orders and calculate how many sold in total and what the price is in a given time period. I have other requirements like this.
Now the data represented in the report will not be like any of the business entities. It will have sums, totals, a field from one entity, a field from another entity... And it will not be persisted it will be generated only for the client to consume. It should be pageable too.
What is the correct approach to tackle this? Do I use pojos to represent the report lines? How do I manage paging with this? Does it make sense to have a repository for each report? Is it possible with hql to return a report line that is not a persisted entity from a repository method?
What would be the easiest and best solution for saving spring header information into database?
I know outbound component that's not the question.
The question is how I can do it without specify-ing header elements in the sql one by one?
Are there any builtin solution for that problem which could adopt the changes when new header elements are added to the message header?
To be honest, there is no such a solution, because with RDBMS we have schema bottleneck.
Even if we could do something like this:
insert into headers value (:headers)
We have to specify any new column in the target DB table.
That's why any NOSQL DB is better for that case. E.g. MongoDb can simply accepts whole Message and stores it to the Document with all headers.
Even if we can Spring Integration scenario make with JPA adapters just to use <jpa:outbound-channel-adapter>, where the message payload is an entity for our header, we need to add a new property to the entity to allow JPA to get deal with them.
However, I think that the new columns in DB isn't en issue for your, and from other side MessageHeader is a Map, so you can iterate over its entries and build INSERT INTO... statement at runtime for each message.
Hope I haven't missed something...
This is a new project we are doing using Spring MVC 2.5, jsp , Java7, Ajax, and HTML5. On my part I am going to have have 7-10 jsp pages which contain one form each.These pages are sequential. i.e One have to pass the first page successfuly to go to the second and pass the second page to go to the third and so on.
The data in order to be persisted, one has to get to the last page (after passing the rest successfully) and confirm the information is correct. Once the user confirms, I have to persist all the data stored in a bean or session (All or none). No incomplete data should be persisted. Let's call our database table "employee"
I am new to Spring MVC but got the idea and implemented the page flow using a controller.
My question is should I need to have one model class or bean to store all the data, or use session to store each pages information and keep it in the session until it gets persisted?
Or its better to have one model class, but multiple controller/bean to control the data flow from each page. Which one do you recommend? Is there any design pattern already implemented to answer my question? If you have a better idea please feel free to discuss your idea.
There are two approaches as you have already mentioned. Which one to use depends on the datasize and other requirements, for example, whether the user can come back later and continue from where he left. The model and controller need not be just one. It can be designed appropriately.
a) Store data from each screen in the session:
Pros: Unnecessary data is not persisted to db. Can manipulate data from within the session when user traverses back and forth on the screens and hence faster.
Cons of this approach: Too much information in the session can cause memory issues. May not be very helpful during session failover.The user cannot log back in and continue from where the user left, if this functionality is required.
b) Persist each screen data as the user moves on:
Pros: Session is lighter, so only minimum relevant information is stored in the session. User can log back in and continue from where the user left.
A separate inprogress db tables can be used to store this information and only on final submit insert/update the data into the actual tables, else the db would contain a lot of unsubmitted data. This way the inprogress db can be cleaned up periodically.
Cons: Need to make db calls to persist and retrieve for every screen, even though it may not be submitted by the user.
You are correct about your use of the HTTP session for storing the state of the forms.
or use session to store each pages information and keep it in the
session until it gets persisted?
because of this requirement:
No incomplete data should be persisted
As for
should I need to have one model class or bean to store all the data
You can model this as you see fit. Perhaps a model to represent the flow and then an object for each page. Depends on how the data is split across the pages.
Although as noted in a comment above you might be able to make use of WebFlow to achieve this. However that is ultimately just a lightweight framework over Spring MVC.