Spring Data JPA from 0-100 in 60 minutes

[Music] since we are talking about are going to talk about JPA I'd like to know who's already using JPA uh uh most of you so why are you here oh I know you don't use spring data JP so who is using spring data JP not everybody okay before I start with a real talk I would like to start with a little story from back in the days in the 70s of the last millennium the last 70s of the last millennium when I was a little kid BMX bikes were all the rage you had to have a BMX bike everybody Muse that except our parents so we had normal kit bikes but the good thing is well for at least for a kid what really is a BMX bike it's a normal bike without all the extra stuff so one afternoon we started to take our bikes apart ripped off the lamps took off the porter I actually shipped off the little metal plate where the porter is true to the frame because it still waits a couple of grams right and you have to get rid of that mudguard gone and then there was this little thing on the axle this one right here it didn't seem to have any purpose so I went to the workshop of my dad got a little metal saw out and saw that thing off and removed the screw from the frame a bang they I had my BMX bike and I took it for a ride on the nearby parking lot and everything went just fine until at the end of the parking lots right before the brushes I tried to brake and I hit the coaster brake and exactly nothing happened except that I go - airborne and landed like two meters behind the bushes so what was happening well this thing here is actually called a talk support and it's an important part of the coaster brake because the coaster brake basically couples this part of the axle which is attached to the rim to the inner part of the axle and here but that doesn't do any good because in a bike this is just kind of clamped to the frame and it will turn with the wheel without any problem in order to prevent that you have the talk support which ties all this to the frame and keeps it from turning and since I removed that my kills the break wasn't basically non-existing anymore so what does have this maybe funny little story to do the Jaypee and spring data JP well as part of my job working at the spring data team being responsible for spring data JPA and spring later JDBC I monitor Stack Overflow for spring data JP questions and my impression is they are basically working or many people I was working in a similar way that I was working back at the kid or house it is described in the Bible they just don't know what they are doing so you are laughing so I guess that means that you are not one of those but even if you are you're here so we are going to change that first thing to understand about spring data JPA is it's built on JP now big surprise so in order to use it you have to understand JP a unfortunately that is not as easy and it might seem from light beginners tutorials of JP a so we will look at a very simple example but then ask some tricky questions that should make clear how JP a works and why it sometimes gets a little confusing oh and one person before the talk approached me and like I want to see if you can convince me that JPA is a good thing because I really hate it that is not my plan I want you to understand how JPA works if you don't know that already and also how Spring NATO JPA works and what it can do for you if you want to do the right thing from a connectional point of view come to my talk on Thursday about spring data JDBC much better but are we go JP JP is all about persistence basically you have tables in your database and you have entities in your java application and these java classes have to be JPA entities and you get that by annotating them with entity and then you also have the attributes which also get all kinds of annotations to tune how these are get mapped to the table or tables an important one is the ID basically every entity needs one to identify it another one is the version which is used for domestic locking you probably want to have that most of the time as well and you can have simple attributes that don't need any annotation and just get mapped to a matching column and then you have more complex stuff like one to one main each one and others that need a couple of annotations to really specify what you want hibernate or Eclipse link which are the dominant implementations of jph do so let's assume we have an entity like this and let's assume a generation type auto for the ID basically means it depends on the database how and where the ID is generated for the following example assume that the ID of the person actually gets set in the clients when you create a person object you set the ID and then coat might look like this to actually work with us you get an entity manager just abbreviated he M up here you create a person and you call entity manager dot persist which should save the person in the database I guess and then you can use for example method like find to get your person back out of the database passing the ID you pass in the type of object that you're looking for and you get it back alternatively if you don't like if you have more complex queries you can do something like this again entity manager create a query based on a J pql query again specify what kind of object you expect set the parameter and get in this case a single result back should again return the same person right but I've put in as comments three places appear after calling persist after finding the entity and down here after career in it and I want you to imagine that there I look into the database with a sequel query for example by using the JDBC template of spring what kind of result would I get on these three please pay oh three places what do you think always one one one one who thinks that is the right answer not many so what else what else could it be I I save it there should be an engine entry in the database right and it shouldn't change because I only read 0 on all three come again yeah there's there's some truth in there but you all use JPA and you'll feel scared to answer this question this is weird right well the answer is actually it will return zero in the first place zero on the second and one in the third place why the heck is that the reason is that as you already hinted ad JPA does something like called delayed writing it tries to write data to the database as late as possible that means the possessed call up at the top doesn't actually possess anything it actually might do an insert statement if it needs to do that in order to determine the ID of the entity like if you have a serial column which creates the IDE on insert that statement will actually perform an insert but if you don't and I claim that we set the ID in the person object manually on the client-side you don't get anything it just remembers okay you have this entity here eventually I have to flush it to the database but then I call find that's for sure going to query in the database right no again because the entity manager works as the first level cache and if you do a find operation it looks into that cache finds out how for that ID I already have the entity so I don't have to ask the database so I get again directly that entity returned without any interaction to the database but then why do I get a change in that with the query well the problem with the query is JPA doesn't really know what's going to happen it doesn't know what you're going to query and it actually has to send that query to the database and in order to make sure that you actually see a consistent set of information from what you just did in your entitymanager session it actually flushes out all the changes to the database so this is why you get a one in the lake in the last position and this kind of delayed writing is kind of cool because it allows JPA to combine statements and batch them if you configure it correctly but it can become really really really confusing if you do something that jpe didn't anticipate and you get weird results and an audience that uses a technology and doesn't really trust themselves to answer a simple question like when does the insert happen so that was on the right side of things it continues what about this method here we ever serve a person service which is annotated as transactional spring annotations or everything all methods in there start a transaction close that transaction afterwards we are to wire the entity manager and we have a set name method which takes the idea of a person and the new value for the name and then it finds that person and sets the first name no pisses no save no merge nothing in there if I actually use that sorry wrong slide if I actually use that method and call from a service set name what will happen will my database state change or not who thinks the database will change okay that's like a quarter who think it doesn't change that's even less and lots of people which are again and sure what's going to happen and I think you had the answer exactly assuming that it gets caught from non-transactional context the transaction would start when entering set name and the transaction will end after it when it leaves that method and again JPA does something really tricky if you load an entity it kinds of keeps connected to that entity and it tracks all the changes to that entity so the entity manager knows that you change that entity and at the end of the transaction we'll flush these changes to the database so you don't have to call save for persist or merge or anything like that which again is cool because it saves a statement and is not cool at all if you want things like you changed an entity but then don't want to persist it all this kind of stuff it will they are obviously they are ways around it but then it starts getting complicated so this is really important to understand the entity manager keeps the connection to the entities as long as the transaction is open and tracks all the changes and flesh flushes them out to the database so basically the second strike or a second point for confusion on the right side now look at the read side there's actually there was another little method in here load person which just find a person by ID and returns it now if I use it like that what do you think will happen notice this is outside the transaction that's the important part any ideas exactly you will get lazy loading exception questioners we're done second line on over here on yet address yeah either second or third what one of the three lines throws an exception it's exactly right it's the third line get address well actually the address will get loaded eagerly by default as when you conflict configure the entity has described earlier on the hobbies won't they will get loaded lazily and what might be even more interesting the get hobbies over here this one that doesn't trigger an exception what triggers the exception is the 4-h because the get hobbies will basically return a proxy collection which just knows well I have to get these hobbies but it doesn't actually do it it only does it when you try to iterate over them or otherwise try to access them so therefore each actually you will try to access the database will notice the transaction is already closed I don't have basically an entity manager anymore that can load the entities for me and throw an exception the exception is actually not that big of a problem because you will notice that during testing the bigger issue behind that is even if you are in a transaction these statements will trigger sequel statements to be executed at some point of time that is basically for an average developer impossible to tell in advance is it that getcha address is it that gets hobbies or only when I iterate over them which might lead to situations where your application performs nicely and then someone does a tiny change somewhere maybe adding a little field in in some web form and showing in another attribute and suddenly additional sequel statements get executed and performance plummets because you have to real a normal method call should be form which like a normal getter which does nothing the time used for that should be somewhere in the range of nanoseconds a round trip to the database is probably more in the range of milliseconds or tens of milliseconds which still doesn't sound like that much but it's thousand times or 10,000 times more than the call that I expected and then that can make a huge difference and I think it's really a problem that you can't see that in their code where it is going to happen the people experience with JPA therefore recommend that you keep the log open for your sequel statements all the time so that you see what sequel statements get executed they actually libraries out there that test that the expected number of sequel statements get executed so that you get an exception with that suddenly changes but again while these tools are helpful and I recommend their use as well it's at least problematic that you can run into these problems just by not knowing how to probably use this stuff but again now you know so this is the basics of JPA you have entities you load them they are kept in this first level cache you can manipulate them and at the end of a transaction JP makes sure all the changes get flushed to the database so what does spring data JP do for you the first thing to notice is it's not a replacement for spring data JPA it's an add-on it's there to make your work with JP a nicer and easier to take away some of the tedious stuff that you otherwise might have to do it's not a replacement means also you still have to know JP a and you still have will work with stuff like criteria RP which is an an API to create queries or JP QL which is basically the replacement for sequel within JP the first thing spring data JP a makes really easy a crud operations create read update delete all you need to do after adding spring data JP a to your dependencies is define a repository like this it's just an interface it inherits from in this case JP a repositories there are a couple of options like crud repository if you don't need anything specific to JP a and there are no methods in there there is no implementation that you need to provide this is done by spring day to JP a itself and you can inject a repository into your application wherever you want and then you can save persons or you can find them or you can delete them or count them I'll check if they exist this kind of stuff really straightforward I guess also not much of a deal if you end that functionality you probably will be able to do that with an entity manager directly but it's certainly nice to not have that the big point about this repository is or like a really common question about that is do I need a repository for each every entity in my application and very clear answer is no you don't need an repository for every entity you need a repository for every aggregate or to be more precise for every aggregate root if these terms confuse you you have basically two options either you look them up in a book or on the web and domain-driven design because that's where these concepts come from or you come again to my talk on Thursday where I will talk about that in way more detail the short version is an aggregate is a cluster of entities that should get handled as one thing all the time the classical example would be an order which always goes with its order IDs our order items especially an order item on its own without an order doesn't really make sense right so the order would get a repository the order items would not you would load them through the order repository and then navigate to them from the order the products on the other side pretty much probably you have a lifetime or lifecycle apart from a very separate from the order so they are their own aggregate and that's the basic idea the next thing and possibly the one that is most famous from the spring data JPA features is crude derivation it works like this again you go back to your personal repository and you add methods like this fight by first name and if you look at a name find by first name you probably in your head know what this is going to do right it's going to create the database for persons that have the name given as a parameter and this is exactly what spring data JPA will do for you spring there to JPA can handle more complex Curie's this way for example another example would be exist by address city contains ignore case if you look at that name you probably also can figure out what that means it navigates oh it creates a where clause which basically navigates across the address to the city and checks if the parameter value given is contained in the name of the city by ignoring upper and lower case but already here you see a very important limitation of crude air it's only intended for really simple curries this is kind of I think they exist but a variant this example already shouldn't be used because the method name is not a nice name but find by first name no there's no reason why you should implement that by hand you like can let's swing data do that and again you can use that just as one would think one uses that if you are wondering why a rest is there the first time I gave this talk was in Bucharest so that curry would actually check if someone is in from Bucharest in the database so if curry derivation isn't for all curries what is well the next level of complexity would be annotated occurs again we go to the repository and now we add a Korean annotation to our method and the Korean annotation or the tree given there can be either a jpq l3 like this one it can also be a sequel query we would need another attribute in the query annotation marking is as a native curry and we can also do what I did here normally if we want to use the parameter in the curry we would just use it with a colon so have something like where a city like colon City but in this case I want to do a little more complex stuff and in this hash curly braces is a spell expression so the way how this works it it takes the city parameter check if it's null or if it's an empty string and if that is the case it just uses the percentage sign and otherwise it uses whatever was given as the parameter string so this is basically a way to load a string construct it here and the Select Clause and define where clause where you can either have it for all values in the database if you provide no string at all or an empty string or you can filter it again by a light query if you provide a value for city and you can do all kinds of stuff with that one thing that is kind of tricky to do or next to impossible with this straight away is pagination you could do it if you use sequel statements but in jpq l pagination is actually not done in the shape in the the jpq l query it's done on the api level so you can't do that because you're not accessing any entity manager but there's a solution for that which is basically that you can move from a query like that to something like that where you just add a page full argument and then you probably want to return a page instead of a list and this will do pagination for you so you have the page table contains information like which page do you want first second third and how big your pages should be and the page itself then will contain the appropriate number of results and some ways to access the next page the previous page and very important it also contains a count of all persons which sometimes can be an expensive cure and if you don't want that there are simple ways to solve that you just return a slice instead of a page slice is very similar to the Paige basically the only difference is it doesn't have this total number of elements and since it since it doesn't have that it doesn't get accurate for for in the database so as it saves a query that you might not need and if you if you don't even need like this this next page and previous page and want to use the page we'll just as a way to limit the number of results you can even return just a list and it would work just as fine there's a question yeah the question was basically with this mechanics it does basically an offset which is both not optimal performance wise and also has the problem if I create for a page then somebody enters at an element into the database that would go into that page and if I then go to the next page I would basically get elements twice or otherwise skip elements and funky stuff like this happens this is an inherent problem with pagination done like this there's a technical better approach where you basically don't say I want elements 50 to 70 but I want all the I want the next twenty elements after this element this is a known technique it's not implemented in spring dated yet so I know there is an issue open up there an unfortunate thing is there are many open issues in it didn't made it up to the front yet but it's something that actually is rather interesting to do but sorry right now we don't offer that unfortunately so the next thing are projections jpay entities can become very complex with lots of attributes lots of references to other entities and often you don't need that if you could maybe you want a certain kind of we port in overview where you only have a couple of attributes that you want to display or that you need to use and in that case projections projections are for you again you take your repository and you take a curry like this which we already had and change it to something like this the important part is that I'm now returning a simple person what that kind of class is you look at it a little later another thing to notice is between the find and the buy there's this simply this is actually completely error irrelevant for what is what is happening on the curry side it's only a way to separate this curry from the one before that which would have otherwise the same name and actually in my example code this is all in one repository and when compiled if it has the same name so you can use that in many cases where your method actually looks the same but you want to have different mechanics behind that by having different annotations at them you can use anything or put anything between the find which defines the kind of career that gets executed and the by which basically prefixes you are your conditions for career on their relations so let's look at the simple person the simple person is just an interface that offers some but not all of the attributes of the original entity and it also has the gate address method which has this value annotation and again in this value annotation we use a spell expression notice again it starts with hash curly braces and ends with the curly brace and you have a spell expression in there which basically assembles string from different attributes with a projection like this we will still load the complete entity and create a proxy implementing this interface so you have the the nice limited interfaces that only offers the information that you need at point you're still performing the full tree if you don't need stuff like this with a value annotation if you just pick a couple of attributes that you want to use in your projection we actually try to limit the query to only the columns and attributes that you're actually requesting an important thing to understand there is that we try to ask JPA to only create the columns that we need but in many cases JPA implementations actually ignore that and they are free to do that according to the specification and still carry more than we actually want that's nothing we can change there's another question I actually don't know I would have to look into the JPA a specification that's basically spring dated JPA basically specifies what columns who want and then jpay does its thing if we like in this case with the value annotation we basically say load the whole entity and I'm not sure how clubs and similar objects are handled in that case by default one more point our conversions right now we always return either a single person or a list of person list being the standard Java list if you and a method returning a person that actually doesn't find a person will will return null in that case if you don't like that if you prefer for example an optional or if you want immutable list and want to use waiver you can do so and spring data JPA does the necessary conversions same applies if you want to have streams or streamable as a return type you can that and spring dated JPA at least in many cases we'll just figure it out the variance we had so far are still all static meaning like all the time every time you call that method basically the same crew gets executed but sometimes that is not what you need you want something where curry gets created dynamically and the first step in that direction is crude by example it's most useful for like search screens where you can enter some or all of the attributes of an entity and then want all entities that match these attributes one way or the other and the way you do that in code as you create actually an instance of that entity a person in this case use null everywhere where you don't care about the results and you enter values where you do care in this case it's the country of the address and the gender of the person and then you create an example of out of that and pass it on to persons find all which I think it's part of the JPA repository interface I might need a special interface it's mark still here no okay yeah might it might be that you need your repository need to implement another interface not completely sure about that and this will query for exact matches so in this case it will won't probably won't find me in the database because if I put the country where I'm from in the database I will write it with a capital capital first letter and it won't find that so in order to tune that you can provide in when you create your example with example of the pattern you can provide an example measure which specifies which attributes it should use equals or like or greater there and smaller then there are different variants that you can use important limitation that often gets asked for you obviously can't do a search for an interval like date of birth between 1970 and 1980 because you only have one attribute in your pattern you can't set two so if you want to use intervals you have to use something different also another problem with this approach is it forces you to have entities that can deal with null values in basically every place which from a domain design perspective is not that nice but on the other hand JPA requires you to have a default constructor so you have the problem that you have null all over the place anyway so not perfect but it's there and it's useful if it fits what you need if you need even more flexibility specifications would be the next step yeah you definitely need a new interface the JPA specification executor and it gives you and you find all methods which takes a specification and a specification is a simple interface that has one method it takes a route which is a JP a data type a criteria query and a criteria builder and returns a predicate which again sorry which again is a JP a data type and basically represents part of where clause this is all nice except it's really ugly I mean if you look at it we have all this these parameters and stuff and it's I can't I mean I work with this for like I don't know ten years or more and I still can't really tell you what is a root and what is the criteria tree these are really weird kind of objects with in my opinion not clear responsibilities and if I pass this thing a basic say okay I want something not to be true and the condition is alike and I work on the address dot city attribute and compared to the city part Oh so I looking for people that come from that don't come from cities that have a new in the name so yeah it does work but it looks ugly it also has another problem using these objects root and criteria actually I can also add group eyes having's I change the can change the select list the problem is that is really not expected by spring data JPA and if you try to do that all bets are off what the results are it might actually work and you're free to do that but if we break it in the next bug fix release sorry we don't take complaints in that case so this is really only for constructing where clauses the better way which you should use if you do that more than like once or twice in your application is use Curie DSL career dsl hooks into your build step in your build process and creates additional objects from your entities and with those you can basically do the same thing as with specifications but in another way you again have additional interface to implement curious a predicate executor the call looks exactly the same the difference is the expression I'm getting here is boolean expression in this case so a true DSL object and we have this queue person which gets created by DSL and allows us to really nicely curry or construct where clauses I think that I use person address dot city contains ignore case city part not doesn't read light English but still is I think easy enough to understand that's basically the same as the previous example but much shorter much more concise sorry I didn't understand that no there's no post processing filtering all the filtering is done by creating career objects given to the entity manager which sends it over to the database returns the result and whatever JPA returns we the only post processing is the conversion that i mentioned so by like the default return values probably a list and you can turn that to a stream or streamable or something but other than that we don't do any filtering on the client side which would be a bad idea to do by default if you do if you need to do additional filtering for some reason you have to do that on your yeah at that point there's time for some advertising I already did that at the beginning people now stumble across bring data JDBC and get get it confused to the spring data JPA the two are very much distinct obviously they are both part of spring data they both work with relational database but with JPA or the mapping is done by JPA and out of our control with the spring data JDBC we the spring data team or this bring data library actually does the mapping to the database and it tries to be much much simpler and as I already mentioned I talked about that on Thursday so either go there or catch me after the talk and we can chat I can tell what we are doing there another question okay so the question basically is you had I guess strange effects or effects that weren't right away obvious to you when another application access the database and wrote into the database and the action question is like how and when does the repository actually access the entity manager and the answer is whenever you have like one of the many variants of career methods these basically all get converted into a query and the entity manager called with that no matter if you use a JP a JP q el Cucuy or sequel query it just goes straight to the entity manager if you use Korea derivation we use the criteria API to create a criteria query and send that to the entity manager and then give you the result back if you do persisting so if you call a repository save what bring data JP a actually does is calling merge on the entity manager which is similar but different to persist it make basically persist assumes that your entity is a new entity and you want to store it in the database for the first time merge is there for if the entity might already exist in the database might even already exist in the entity manager but you now have this detached entity basically one that you just created posit to the entity manager and the entity manager will actually return possible the entity that it already has so you might get back a different object anywhere will make then track this entity and make sure that changes get eventually flushed and the flushing but actually happens whenever JP a thinks it's the right time to flush which basically means if you have a brand new entity and the ID gets generated the database it will create an insert right away in order to get that ID otherwise it will do nothing at the moment that you're calling it but when the transaction ends it will flush all the changes also if you perform a query again no matter if you provided manually if you access the entity manager directly or if you use crude derivations all the other I mean they will basically execute the query and therefore trigger a flash by default configuration there's a lot of configuration obviously that you can change but this is other points where flush happens and of course before a transaction ends maybe a word about transactions in most applications you probably have some kind of service layout something which is transactional and reps multiple actions in one transaction if you don't do that all the repositories are annotated as transactional so if you don't specify any transactions at all every single core to a repository will live in its own transaction that's that's another thing maybe to note what you just mentioned if you switch from one database to another basically every database out there has their own exact way of doing transactions some lock and read some don't and all kinds of differences and these differences aren't fully equalized by JPA which means that you although JPA gives you the impression that it's database independence you still especially have to transact and how locking behaves you get differences that might cause problems if you especially if you either switch the database or if you use one database for testing and try to use another one for projection don't do that there's like for a year or two I think there's this library out there test containers which basically allows you to from Java code very easily to create any kind of instance rep in a docker container and it works great for databases in tests so you use your real database put it in a docker container if it doesn't already exist one and use that for testing so that you get the exact same behavior in your tests as in production very good point which kind of brings us to two troubleshooting I already mentioned I think that part of my job is tracking Stack Overflow for spring data JPA questions and one thing as mentioned before I notices a lot of people use JPA but doesn't understand it I think there are about 100 people less now that have that problem another problem that I see is people don't understand what is spring data JP a and what is JP a I hope I gave you a little impression of that and I really urge you when you encounter a problem you get don't get the results that you want you might get an exception try to find out where the problem is is it in spring dated JP a or is it in JP a or the JP a implementation rules of thumb sir if it is about Cole about conversions like you perform a curry and the repository method you get an exception basically saying I can't convert this to that that most of the time is a problem in spring dated JPA or with the use of spring day to GBA if the result is wrong at all this also might or is kind of likely a problem with spring dated JPA either in spring later JPA itself or with the usage of it maybe you used derive Curie and you used the curie name constructed the method name wrongly then you get exceptionally man everything was concerned with mapping and eager or lazy loading is almost certainly a JPA problem not a spring day 2jp a problem because all the mapping is done by JP we don't do anything with that you might think well this guy just wants to make his job easier what yes I do but it's actually in your own best interest because if I look at the Stack Overflow questions I see a question of this tech stack sorry tag will spring data JPA I look at it and if I see it's just a mapping problem I just move on most of the time because I think well that's I guess I might be able to help but I have lots of people that actually need help with their spring data JPA problems so I rather help them but especially if even in the title or in the question like I have this problem with spring data JPA if a hibernate person comes along he looks at that and says well that's a spring data JPA problem not my problem so you don't you don't get an answer so if you're not sure if it's JPA or spring day JPA question make that clear in the question and use both tags then both of us will look at it and probably one is able to help you so I think it's in your own best interest yeah thing look at of course post you stack traces to stack overflow yes all the stack traces I know Springs tech traces can be long and hibernate doesn't make it better but also learn to look at your state traces they a lot of like cryptic stuff in there probably related to spring proxies or hibernate proxies that makes these confusing but a Java exception has always a message and the hibernate guys the clips and guys the spring guys everybody tries to make these except of these messages as good as possible so it might very well be that the problem is very well described in that message so read it and try to understand it and an exception typically has another exception as a course and that might have another exception as the cause and all these have messages too so at least read all these messages and then you might or in many cases might be able to resolve your problems yourself and if not you're in a position to ask much better question I don't want Stack Overflow or wherever you like to ask your questions that's basically it if you want to learn more there are links to the git er project if you especially want to submit pull requests which are always welcome although I sometimes need quite some time to process them the reference documentation there's a github repository lots of examples for spring data JPA and other spring data modules the example code for the slides is in a repository on github and finally for this specification career dsl stuff there's a really good example in the spring blogs and if you want to contact me or just make sure that I don't talk to you this information might be of value I'm Ian Chawla I work for pivotal in the spring data team the responsibilities are spring day to JPA which I talked about today spring Natick JDBC which I will talk about on Thursday there's my email address and if you want to chat me up on the right side are topics that might be useful to get me talking so I'll be here for the rest of the conference so if you have questions find me and I think we have like I don't know I I'm actually not sure when we need to finish the next talk start at 10 bucks past three we have now two minutes to three so if there are any more questions I guess one or two we could take any questions there's one there I think there are a couple databases that offer that are actually no sequel databases but offer a sequel layer and that might work if they offer a JDBC driver but that would be a question for the specific database normally it's just for relational database they spring data for other modules or other spring data modules for many no sequel database like MongoDB neo4j Cassandra solar many more they are not like independent that you can just swap one repository for another but they're very similar so you find your way around and can concentrate on your business domain and the specifics of the database to use that as well as possible there's well the question was are there any any patterns or antipatterns things that one should do or shouldn't do there are a lot of there's a lot of information about that for JPA out there although I can't like point to a single resource it also depends a lot on who's writing that like there's a great book high performance with with JPA by vladimir al khair which is one of the the hibernate guys which is great it as the title says focuses on performance and actually makes suggestions that make me cringe because they are kind of the opposite what I would do from a domain-driven design perspective so it's really difficult to come up with a consistent set I don't think there are any patterns out there like that for spring day toes bring data JPA it's actually would be probably a good idea to do that I'm thinking about doing more blog posts about like looking at specific technical challenges and then have a blog post that so maybe that it was something like that one thing you mentioned not directly meant accessing an entity manager I think that makes sense as a baseline rule there's actually one important feature that I would like to add maybe as a last one when like all the methods that Spring NATO JPA offers aren't sufficient for you because you want to do something completely different maybe you want to create your career completely dynamically you still like as last measure of what we call custom methods where you basically provide the implementation for a method in your repository so you can do all your custom stuff still inside the repository but basically can do whatever you want you can inject an entity manage their use that you can you can inject Juke which is another library for accessing relational database and use that in there so all options are there and we try not to get into a way we try to make things easy that that we can make easy because they are used often and are straightforward and try to get out of your way if you want to use if you want to do something that only that you know how to do that I think maybe the rep again if you have more questions I will be outside also you can find me at the conference probably best attack me on Twitter or something so we can meet somewhere have a nice day [Music]

Channel: VMware Tanzu

Views: 60,166

Keywords: pivotal software, agile development, pivotal labs, cloud native, big data, data science, pivotal cloud foundry

Id: Zyqpo8gxSO0

Length: 62min 31sec (3751 seconds)

Published: Wed Oct 16 2019