* 이글은 Udemy의 https://www.udemy.com/course/spring-framework-web-development-2020/
강좌를 듣고, 스스로 공부한 내용을 정리하기 위해 적는 글입니다. 정확하지 않거나 부분 부분 연결되지 않는 정보들이 있을수 있습니다.
So in this employee we've got the field project multiple employees could be assigned to the same project.
(이게 지난시간까지 한 내용. Employee클래스의 project리스트변수를 생성. 그 프로젝트 변수에 다수의 employees들이 할당가능하다.)
Now the thing is this Many to One annotation has some parameters that we should use.
Let's say, for example, we wanted this situation where if the project was deleted you know project is the parent entity and the associated employee is the associate employees for that project should also be deleted. If we wanted to have that functionality we'd have to specify some rules for this @ManyToOne. And those rules go into this parameter called Cascade type or cascade rather.
CascadeType치고 점누르면, 아래의 여러개의 타입들이 나옴
So what is cascading?
that basically means that if something happens to the parent entity, the owning entity, we want all of the children to also go through the same step. So let's say that we we use this remove cascade type that means that if we were to delete the project from the database, we'd want the employees that are associated with that project, we'd like them also delete it. That's what this remove represents. DB에서 프로젝트 삭제하면, 그 프로젝트에 할당된 employees들도 삭제가능하게 하는. 그런 아규먼트.
Casade의 더 다른 다양한 argument들은 아래와 같음~~
all- means that all of these other cascade rules apply.
refresh - if the parent is refreshed the child will be refreshed. ex) let's say you run a refresh query on the project, The children should also be executed to refresh and bring in fresh children and the employees that are associated with that project
merge - if the project gets merged with another project we'd also want the respective employees associated with that project to be merged as well. ex) let's say project A you merge with Project B, the associated children of project A better also move over to B.
persist - the ability to save to a database right. So if you save the parent entity you want to make sure that the child is also persisted in the database
detache- detaches a scenario where you detach the list of employees from the actual parent.
Casade는 여기까지 있고.. 또다른, Fetch라는 아이가 있음.
fetch란,,?
javax.persistence.FetchType
Defines strategies for fetching data from the database. The EAGER strategy is a requirement on the persistence provider runtime that data must be eagerly fetched. The LAZY strategy is a hint to the persistence provider runtime that data should be fetched lazily when it is first accessed. The implementation is permitted to eagerly fetch data for which the LAZY strategy hint has been specified.
페치타입에는 Eager와 Lazy가있음... (사담인데, 참.. 그뭐냐,, 작명하신분.. 되게 직관적이고,,,, 참,, 그,, 직관적이고 단순하게 잘 지으셨다! ㅎㅎ,, 뭐..좋고나쁘다가 아니라 걍 그렇다구! ㅎㅎ 데이터를 열렬하게 가져오고 게으르게 가져오는구나! 촤햐하!!)
Lazy가하는 기능이 뭔지 좀더 자세히 말하자면,
So a lazy approach would be that we get only the employees associated with one project that project
that we are considering. When a given project is loaded all of its respective employees are loaded and
for that kind of functionality we use FetchType.lazy. if we use the lazy approach, we load projects into the memory ,but not the associated children like all of the employees that are associated the project that's not going to load them.
lazy로 페치하게되면 프로젝트 로딩될때, 할당된 자식엔터티들도 다 로딩되는게 아니라, 우리가 고려하는 프로젝트와 그 프로젝트에 할당된 employees데이터들만 fetch하게됨.
FetchType.eager that could actually slow our application down because the main difference between FetchType.lazy or fFetchType.eager is the way the data gets loaded into the memory of the application when the applications are running.
Lazy와 Eager의 가장 큰차이가 어플리케이션이 실행중일 때 메모리에 데이터를 로드하는 방법이 차이임.
if we use the FetchType.eager approach, when you query the database, for example, let's say you query for four
or five different projects, all of the associated child entities or the employees that are assigned to those products are also going to be loaded from the database at that same time. And that's called Eager loading and we don't want that that's going to slow things down.
그런데 Eager로 페치하게되면 어플리케이션 로딩을 느리게 할수..아니 느리게 만듬. 예를들어.. 우리가 4~5개의 다른프로젝트들에 대하여 쿼리를 실행한다 했을 떄, Eager로 페치하게되면 모~든 할당된 자식 엔터티들, Employees들이 프로젝트들만 로드 되는게 아니라 "같이"로드됨. 그러니까..결과적으로 로드되는 애들이 많아지니 어플리케이션이 슬로우 다운 될 수 밖에!
So using a lazy approach we can actually just load the projects and if we need to access the employees we can actually make that call separately later. and only then for the particular project that we are interested in will the employees be loaded into our application.
그래서 걍 Lazy를사용하면 프로젝트만 로드하고, 우리가 employees에도 접근하고싶으면 그 요청을 개별적으로 나중에 처리할 수 있음.
So this is just a thing to keep in mind in terms of performance, always use FetchType.lazy unless
you absolutely need to do FetchType.Eager and for most of the situations FetchType.lazy will
do just fine and that is the industry standard so try to use that lazy loading is is it is a very important
design pattern when it comes to performance improvements you can use the same annotation parameters.
결론:
그래서..결론적으로. 퍼포먼스에관하여서도, 업계 스탠다드로서도 FetchType.lazy를 쓰는게 낫고, 그렇게 다들 씀.
All of these you can use them on the other side which is the project side you know the one to many side but we don't need to use them in this situation. later we'll go over an example where we need this kind of parameters on both sides of the relationship.
So for now we're just going to stick with keeping the cascade rules in the many to one side which is the employee.
And hopefully you understand why this is the child side right. You know many employees can work for one project and so these children are where the cascading rules should be placed in the event that when something happens to the parent(프로젝트), the children are programmed to do what they are according to these rules. so we don't have remove as a cascade type here. So it's safe to go ahead and delete a project and the children will not be deleted.
If we had remove as one of the options here for Cascade rules once a project is deleted so will the
associated children and we don't want that. OK with this existing configuration we just really care for when the project is saved to the database all of the associated children of that product should also be saved.
And that's why we have cascade type that persist. Now the rest of these rules such as detached merge refresh are not as important as persist or remove but they're important to know about.(그러니까 사실상 Persist랑 Remove사용을 가장 잘 알아두면 좋고 나머지 rule들은 그냥 "알아두기만"하면 된다는 뜻)