I intend creating a restful webservices with spring and Datanucleus JDO for persistence.
I have read a couple of materials and i think i understand safe for some grey areas.
I have created my domain/Model classes but unsure of certain things. Here are my questions
1) Is it possible to annotate my persistent Classes with #XmlRootElement and #PersistenceCapable. I ask this because the same persistent classes will be marshalled and unmarshalled to and from xml.
For example
#PersistenceCapable
#XmlRootElement(name="miscode")
public class MisCode {
}
2) I already have a database i need to connect to, so how do i map each Model e.g(MisCode.java) class to it's corresponding table name in the database. Is the .orm file necessary and where do i put it?
3) Is persistence.xml necessary and where does it come in?
Thank you all.
Why wouldn't two independent annotations be usable?
Why not read the docs for DataNucleus about how to map to a schema?
http://www.datanucleus.org/products/accessplatform_3_0/jdo/orm/schema_mapping.html
No. As above, read the docs of the JDO implementation you chose, or read the JDO spec.
Related
We would like to share the Employee across both applications exposed as micro services. But Employee has the JPA definition, how do we package this is as a separate jar which can be shared across multiple applications
Spring Boot "AppA" has following entity
#Entity
#Table (name = "employees")
public class Employee {
}
Spring Boot "AppB" fetches Employee from "AppA"
ResponseEntity<Employee[]> response =
restTemplate.getForEntity(
"http://localhost:8080/employees/",
Employee[].class);
Employee[] employees = response.getBody();
You have to wrap the Entity first in a Record and then use
Corba-SCNR version 3 to access it from the other service.
Alternatively, you might want to rethink your
microservice-architecture, as its not good to have two services access
the same entity/database.
Ok, trolling time is over.
To answer your question: you cannot share an Entity over REST between two services in a way that is still giving you the guarantees defined by JPA/Hibernate.
Why is that? Because the EntityManager in JPA/Hibernate creates a wrapper around the Java Object you have, intercepts calls to it and kind of remembers when you change some fields so it knows which sql statements to generate when you "flush" the changes to the database. These wrappers cannot be serialised over your REST Endpoints, at least not in a way that another service could pick them up and continue where the first service stopped.
In general, it is a bad idea to directly expose your JPA Entities in your REST Controllers. I personally prefer to create small DTOs ( Data Transfer Object ) that I fill with the data that I need to expose and only expose those in the REST endpoints.
So best would be to think about "which information does AppB need from the Employee" and put theses in the DTO, then expose them in the Controller of AppA.
If you need to make changes to the Employee in AppB, create a controller in AppA that accepts requests from AppB and then send a request from AppB to AppA.
Depending on the size of the EmployeeDTO you create, you could put it into a shared jar or simply copy it over. Depending on the size of your project, you could also describe it in Swagger/OpenAPI in AppA and generate it in AppB, but this might be overkill.
I hope this helps a bit. Sorry for the trolling before.
If you really need to share them and do not want to copy and paste you can achieve that by packaging your shared entities and repos on a separate Spring project (without an Application.java) and declaring that project in your downstream services as maven/gradle dependency.
Let's say you've put the entities and repos in a separate library under the following packages:
Under a package like my.common.lib.entities, my.common.lib.repos
You can make Spring discover them on your downstream services AppA and AppB by using #ComponentScan typically on your corresponding Spring Application classes:
AppA:
#ComponentScan(basePackages={"my.common.lib.entities", "my.common.lib.repos"})
#SpringBootApplication
ApplicationAppA {
}
the question is simple, but I can't find any of answer about this.
After searching, I realize that kotlin data class is not suitable for Spring JPA because data class is immutable and does not support inheritance.
So, I wonder are there any alternatives for JPA which support data class.
Thanks,
I find two kotlin-based ORM, ktorm and exposed.
It seems both are very good for start, and it supports data class.
But, at some point, I thought that I need to move to ktor rather than Spring boot when I wanna use kotlin more kotlin-tic way..
Im working on a system that uses byte buddy to generate some classes on runtime, specially entities, that are created from a json schema file. My question is, can I provide to Spring Data the classes generated by bytebuddy or it will only work if the classes exist in disk at startup?
I started to read this tutorial: spring boot tutorial
In this I read that under model module they implemented POJOs and Repository interfaces. -> tutorial on github
In Repository interfaces I found two methods without implementations:
findByUsername,
findByAccountUsername.
My questions are:
How does it work when those methods in repository interfaces have no
implementations and those are not inherited from any super class?
Does it work with name conventions and reflections?
Does Spring Data has inmemory database to work with?
(1) How does it work when those methods in repository interfaces have
no implementations and those are not inherited from any super class?
The Repository interfaces are being implemented (backed up) by Spring Container at Runtime.
(2) Does it work with name conventions and reflections?
Yes, it works on naming conventions and spring container uses JDK's proxy classes to intercept the calls to the Repository.
(3) Does Spring Data has inmemory database to work with?
No, Spring does not use any inmemory database
Please refer the below link for more detailed explanation:
How are Spring Data repositories actually implemented?
For your question 1 and 2, they are right. They use naming convention and reflection. If you don't want to use their naming convention, you can use #Query with HQL, and certainly the hidden class (which implements for your interface) will handle these query also (you don't need to roll the implementation out).
For your last question, as list of IMDB here: https://en.wikipedia.org/wiki/List_of_in-memory_databases , spring data is not supporting for them. You must invoke another Java driver or spring product for each one.
Does anyone know any Java frameworks that follows the repository approach with automatic implementation of query methods (e.g. findByNameAndLastName(…)) but not tied to Spring, only pure JPA. Such feature also exists in GORM. I would like to see if there is any project that can be used in Guice or pure JavaEE environment without bringing Spring as a dependency.
(Disclaimer: I am the author of Spring Data JPA)
There is the CDI Query Module which is very similar to what Spring Data JPA. There's also a DeltaSpike module.
Note that Spring Data JPA ships with a CDI extension that creates repository proxies as plain CDI beans and does not bootstrap a Spring container. There are APIs that allow the creationg of repository proxies programmatically such as:
EntityManager em = // … obtain EntityManager
JpaRepositoryFactory factory = new JpaRepositoryFactory(em);
UserRepository repository = factory.getRepository(UserRepository.class);
Yes, it still requires Spring libraries to be present on the classpath but it is then using them similar to how you would use Commons Collection or the like. We try not to reinvent the wheel and the Spring libraries we depend on provide a lot of useful code that we do not have to re-code.
So if it's Spring as DI container you're worrying about, feel free to give the CDI extension of Spring Data JPA a choice. If you don't want to use any Spring whatsoever (for whatever reason), have a look at the alternatives.
Based on Oliver's information, followed up as also interested in this topic --
CDI Query joining Deltaspike mail thread: http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Porting-the-CDI-Query-extension-project-to-DeltaSpike-td4329922.html
Deltaspike base link: http://deltaspike.apache.org/index.html
Getting started: http://deltaspike.apache.org/documentation.html
Just did their 0.4th release as of 5/31/2013.
However, have not done enough of a review to contrast/compare Deltaspike versus Spring-Data w/ CDI extensions (spring-data being very mature).
Take a look at Tomato on github!
It is a functional replacement for Spring JPA, has zero dependencies, performs better and is far easier to use. It will reduce your data access code by 98% and deliver the results you want right out of the box.
https://rpbarbati.github.io/Tomato.
If you want free, fully functional dynamic forms and/or tables for any Tomato entity or hierarchy, that can also be customized easily, try the angular based companion project...
https://rpbarbati.github.io/Basil
Both are current, maintained projects.
Try it yourself, or contact the author at rodney.barbati#gmail.com with questions.