Gavin King - great API designer I just have minor suggestion - in the generate JPA code it will be nice to have input method parameters as part of the exception message at least to have diagnostic with which input parameters the query failed I use as part of my coding and it save me a lot analyzing time :)
Thanks, you've given me something to think about. My knee-jerk reaction is I don't think you want this for *every* exception (I wouldn't want to attach the repo method arguments to, say, an error saying we couldn't communicate with the database, or that a lock timed out, or whatever.) But I agree that for things like NoResultException or NonUniqueResultException it would be useful. What I need to look into is whether there are other similar cases.
the thing is in DDD we can't use @Entity or any other framework dependency in model module. Spring has a solution with custom annotations added to bean discovery but i'm not aware of Jakarta solution for the same problem.
Neither @Entity nor any other JPA annotation constitutes a framework dependency . You can load your entity class and instantiate it with 'new' as a plain Java object in a JVM where neither Hibernate nor the JPA API jar is present and everything will work just perfectly. The only thing you won't be able to do with your entity class is persist it via JPA (obviously). On the other hand, these annotations express essential information about the semantics of your model with respect to persistence, and their presence makes your entity class much easier to read and understand. Externalizing the information expressed by the JPA annotations to a different place (XML, or wherever else) is in almost all contexts a terrible idea, and only harms maintainability of the code.
Hİ @@GavinKing, ""these annotations express essential information about the semantics of your model with respect to persistence," persistence is external worry which has nothing to do with model itself therefor has no place in model. I should be able to switch persistence provider(JPA, JDO, SQL, even maybe external services) without changing model it is reasonable thing to expect because of that external XML is the only "reasonable" path to go forward with JPA. which is not beautiful comparing to custom annotations spring offers.
@@ebuzertahakanat "persistence is external worry which has nothing to do with model itself" It's precisely this belief that gets people into trouble when doing ORM. The idea that the Java model is somehow independent of the relational schema is a path to failure, as we've seen over and over and over again. "I should be able to switch persistence provider(JPA, JDO, SQL, even maybe external services) without changing model " This has never happened once in the whole history of the computing industry. [Such migrations always impact the Java model to some extent.] In the presentation above, I explained one reason why it's impossible: there's a fundamental difference in the way data is represented in a hierarchical/document model vs. the relational model. Relational data is not made of trees.
@@GavinKing " This has never happened once in the whole history of the computing industry. In the presentation above, I explained one reason why it's impossible" this is simply not correct. In past i have switched from JPA to JDO to use Hbase in one of my projects. Also apart from that to be able to compare persistence provider to simply benchmark and test is a Use Case for many. Without that how we can choose knowledge based? I also witnessed a JPA project to switch to Mongodb i was not part of that project. This is happening more frequently with the changes in Data Store landscape. sql, nosql, newsql, Firebase like external services etc. etc.
@@ebuzertahakanat I don't know much about HBase but it looks like it stores data in tables. It doesn't look like a hierarchical/document database. I'm not saying it's impossible to migrate between databases which store data in tables [without any model changes]. That's a perfectly common thing to do, and one could, I assume, reasonably implement JPA for HBase. On the other hand, migrating a nontrivial data model from a relational database to Mongo would definitely result in changes to the Java entity classes. Relational data is not made of trees; document data is.
I was waiting for this one. Thanks Gavin! Great talk!
Thanks!
Gavin King - great API designer
I just have minor suggestion -
in the generate JPA code it will be nice to have input method parameters as part of the exception message
at least to have diagnostic with which input parameters the query failed
I use as part of my coding and it save me a lot analyzing time :)
Thanks, you've given me something to think about.
My knee-jerk reaction is I don't think you want this for *every* exception (I wouldn't want to attach the repo method arguments to, say, an error saying we couldn't communicate with the database, or that a lock timed out, or whatever.)
But I agree that for things like NoResultException or NonUniqueResultException it would be useful. What I need to look into is whether there are other similar cases.
Can I have the demo source code please?
How much does this talk relate to what we find in EFCore with DbContext having DbSets?
the thing is in DDD we can't use @Entity or any other framework dependency in model module. Spring has a solution with custom annotations added to bean discovery but i'm not aware of Jakarta solution for the same problem.
Neither @Entity nor any other JPA annotation constitutes a framework dependency . You can load your entity class and instantiate it with 'new' as a plain Java object in a JVM where neither Hibernate nor the JPA API jar is present and everything will work just perfectly. The only thing you won't be able to do with your entity class is persist it via JPA (obviously).
On the other hand, these annotations express essential information about the semantics of your model with respect to persistence, and their presence makes your entity class much easier to read and understand. Externalizing the information expressed by the JPA annotations to a different place (XML, or wherever else) is in almost all contexts a terrible idea, and only harms maintainability of the code.
Hİ @@GavinKing, ""these annotations express essential information about the semantics of your model with respect to persistence," persistence is external worry which has nothing to do with model itself therefor has no place in model.
I should be able to switch persistence provider(JPA, JDO, SQL, even maybe external services) without changing model it is reasonable thing to expect because of that external XML is the only "reasonable" path to go forward with JPA. which is not beautiful comparing to custom annotations spring offers.
@@ebuzertahakanat "persistence is external worry which has nothing to do with model itself"
It's precisely this belief that gets people into trouble when doing ORM. The idea that the Java model is somehow independent of the relational schema is a path to failure, as we've seen over and over and over again.
"I should be able to switch persistence provider(JPA, JDO, SQL, even maybe external services) without changing model "
This has never happened once in the whole history of the computing industry. [Such migrations always impact the Java model to some extent.] In the presentation above, I explained one reason why it's impossible: there's a fundamental difference in the way data is represented in a hierarchical/document model vs. the relational model. Relational data is not made of trees.
@@GavinKing " This has never happened once in the whole history of the computing industry. In the presentation above, I explained one reason why it's impossible"
this is simply not correct. In past i have switched from JPA to JDO to use Hbase in one of my projects. Also apart from that to be able to compare persistence provider to simply benchmark and test is a Use Case for many. Without that how we can choose knowledge based?
I also witnessed a JPA project to switch to Mongodb i was not part of that project. This is happening more frequently with the changes in Data Store landscape. sql, nosql, newsql, Firebase like external services etc. etc.
@@ebuzertahakanat I don't know much about HBase but it looks like it stores data in tables. It doesn't look like a hierarchical/document database. I'm not saying it's impossible to migrate between databases which store data in tables [without any model changes]. That's a perfectly common thing to do, and one could, I assume, reasonably implement JPA for HBase.
On the other hand, migrating a nontrivial data model from a relational database to Mongo would definitely result in changes to the Java entity classes. Relational data is not made of trees; document data is.
15 minute grill of Spring Data JPA 😁
What is wrong with that? The criticisms are totally legit.