Timeline for Best way to handle lazy models with mapstruct and spring transnational scope
Current License: CC BY-SA 4.0
26 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Jan 19, 2021 at 10:01 | history | bounty ended | CommunityBot | ||
| S Jan 19, 2021 at 10:01 | history | notice removed | CommunityBot | ||
| Jan 11, 2021 at 15:00 | history | tweeted | twitter.com/StackSoftEng/status/1348645895059996677 | ||
| Jan 11, 2021 at 14:16 | answer | added | Marc | timeline score: 1 | |
| Jan 11, 2021 at 13:19 | comment | added | Youans | Thanks that was a pretty good discussion +1 | |
| Jan 11, 2021 at 13:11 | comment | added | Laiv | I have upvoted the question because now I'm interested in how other developers solve this. | |
| Jan 11, 2021 at 12:51 | comment | added | Youans | I might be touching a technology limitation but I posted that Q in order to gather more info how other developers deal with that situation | |
| Jan 11, 2021 at 12:50 | comment | added | Youans | Yeah I see, but if you read about it more, it is a very bad idea to open a transaction outside the business layer, as some developers suggest to always encapsulate transactions open/close in business layer since it is a pricey operation to do you have to manage it from one place, and I totally agree with that TBH | |
| Jan 11, 2021 at 12:48 | comment | added | Laiv | Because you want the controller to interact, solely, with the service. You still can make calls to the repository. Spring provide several Repository Interfaces (crud, query, criteria, etc). Some of them can be casted as read-only once injected in the controller. Or make your own read-only interface and use Spring Data | |
| Jan 11, 2021 at 12:48 | comment | added | Youans | The solution #2 is similar to Scenario#3 I have in post, but what you are suggesting is different since yours would be creating couple of different transactions but same idea but opening more connections/TX is not an option IMO | |
| Jan 11, 2021 at 12:46 | comment | added | Youans |
Ofc it's contextual, if I can afford 2 calls I do, if not, the business service becomes a little bit more complex exactly I was stressing that the service will end up having alot of methods some of them do the exact logic but with different returns or arguments
|
|
| Jan 11, 2021 at 12:45 | comment | added | Youans | #1 is pretty much what in Scenario#1 but problem here is that I will end up with having 2 methods one that returns a dto (used by controllers) and another that returns model (used by other services) | |
| Jan 11, 2021 at 12:41 | comment | added | Laiv | Well, you have (at least) 2 easy solutions. #1, the service itself fetch all the lazy data before return. #2, Controller gets the data as is from the service and do perform a second call to the repository/service asking for all the data. Or just attach the entity to a new session and fetch the remaining data. When I go #2, my transactional methods do return a reference to the entity. The whole entity should be retrieved by a second query. Ofc it's contextual, if I can afford 2 calls I do, if not, the business service becomes a little bit more complex (#1). | |
| Jan 11, 2021 at 12:38 | comment | added | Youans | Usually all of my services are DB operations, but I see your point that maybe I would have a service that communicates with a 3rd party on that case I don't need a transaction that was provided by the annotation on the class, I can see this would be better to have it on the method but apart from that, what I'm digging here about is the lazy exception vs mappers | |
| Jan 11, 2021 at 12:34 | comment | added | Laiv | In a nutshell, you must define the boundaries of the business transaction, not everything in the business layer falls within a business transaction. | |
| Jan 11, 2021 at 12:34 | comment | added | Youans | Well I found there is a big discussion about that here stackoverflow.com/a/818131/1460591 | |
| Jan 11, 2021 at 12:33 | comment | added | Laiv | Not true. Well, at least I never did so and I had no issues of DB access. Transactions are a business concept, not a technical requirement imposed by the framework | |
| Jan 11, 2021 at 12:32 | comment | added | Youans | In Java with Spring it does, every call to DB should be wrapped into a Transaction context, this keeps connections to DB properly managed by the application container (Spring) | |
| Jan 11, 2021 at 12:30 | comment | added | Laiv | It doesn't change the fact that fetching the data from the DB for querying doesn't need to be transactional. Just provide CarReadService with non-modifier methods. That should be enough to ensure that nobody uses CarReadService to write/update the DB. Anyways, If the Service is only acting as a gateway to the repository, just call the repository from the Controller. Repositories are high level abstractions | |
| Jan 11, 2021 at 12:28 | comment | added | Youans |
@Laiv Well, I just wanted to simplify the code in the post but usually, what I do is to have a Read Only transactional services e.g CarReadService annotated with @Transactional(readOnly = true) and a read/write transactional write service CarWriteService annotated by @Transactional
|
|
| Jan 11, 2021 at 12:15 | comment | added | Laiv |
Making a whole service @Transactional doesn't seem (to me) the way to go. Usually, some methods are others are not. get**** usually are not.
|
|
| S Jan 11, 2021 at 8:49 | history | bounty started | Youans | ||
| S Jan 11, 2021 at 8:49 | history | notice added | Youans | Draw attention | |
| Jan 8, 2021 at 14:48 | history | edited | Youans |
edited tags
|
|
| Jan 6, 2021 at 13:59 | history | edited | Rik D |
edited tags
|
|
| Jan 5, 2021 at 13:44 | history | asked | Youans | CC BY-SA 4.0 |