Detached objects in standalone Java SE Client: Netbeans uses autogenerated DTOs? - client-server

I have a problem:
I am working at a Java EE project, the GUI is writting by other persons.
I cretaed the database
I wrote a Java SE application (with Netbeans 7.1) which contains the entities (I let Netbeans generate these from database and fitted them)
I wrote the testclasses, wrote the ejbs and tested them.
I than wrote a singleton webservice in which the other beans are injected.
I the webservice, I got the expected result: it's possible to get the list of all instances (rows in the database), get an instance of an instance by ID, update and save it: all CRUD operations are OK.
In the Client, a Java SE Application (with Netbeans 7.1), I added a "web service client" by specifying the WSDL URL (of the webservice created in 6).
All what I got are detached objects. Every object with its all fields (as strings) EXCEPT THE ID (Primary Key).
instead of an update, I got an insert (cause the edited object has no ID on the client).
Remove doesn't work at all.
Other operations (findAll, findById) are OK.
Do I have to use DTOs (Data Transfer Objects)? I read that these are not more needed as of ejb3.1
On the client, for a findAll operation, Netbeans does not accept to use the entities: it forces me to use the autogenerated "dtos", which have almost the same fileds (except thhe primary key or ID) as the entities but as strings.

Problem solved.
I don't know why but Netbeans has autogenarted DTOs without the primary keys, therefore not all CRUD were possible.
This took me a long time and caused lot of headache!
Meziane

Related

Spring data JPARepository findById() on an Entity with #Version persists the record when no data is present for the primary key

Am using Spring Data JPA and hibernate in as springboot project for persistence, Whenever the method findyById() method on the Repository(JPA CRUD Repository) returns no data for the Primary key for an entity which uses #Version annotation for optimistic locking, it tries to insert an entity to the database.
I could see the insert query generated in the log file.
Has anyone come across such an issue? Please help.
The things I noticed from your explanation seem very strange to the program because this should not happen, you are just doing a simple query, it should not depend on the output of the query. Consider how much you have to look at different situations in very large application to avoid unexpected behaviors that cause problems.
One of the goals of ORM (Hibernate, etc.) is to ensure that the application meets your needs without worries.
There may be configuration on the side of your existing application that cause this problem.
In my opinion, to understand the problem, create another simple project with the minimum requirements, try again.

Managing database content on jhipster server

How would one go about managing the data in their PostgreSQL database on their JHipster generated server? My goal is to be able to periodically check the items in the database and perform certain tasks based on the database contents.
I'm new to using JHipster and I'm not sure how I'd go about adding or removing entities as well as adding items to entities on the server. I understand that services facilitate doing these operations for the client-side, but I can't see how I would use the same approach to do what I need on the server (if this is even the correct approach).
To schedule a task on backend you can annotate a public method of a service with #Scheduled, you can find an example in the code generated by JHipster in UserService class look at the removeNotActivatedUsers() method.

connect to database retrieved at runtime using spring + hibernate

I am using spring + hibernate transaction manager in the my project. Initially I am connecting to main database and retrieving several projects in a company, say if there are 200 projects each project will have database associated with it, I want to connect to database associated with the project that is selected by user at run time.
Is there any ideal way to connect to database at run time?
There's a Spring abstraction AbstractRoutingDataSource that has been around for a long time, and that fits your bill
The general idea is that a routing DataSource acts as an intermediary
- while the ‘real’ DataSource can be determined dynamically at runtime based upon a lookup key.
There is a good post and a newer tutorial, where you can learn more details.

making changes to database with hibernate

so im quite new to all spring and hibernate so i used a feature in myeclipse called generate CRUD application (it uses spring and hibernate for the heart of the application and JSF for presentation objects)that im intended to make changes so that i can work with .. my question is the following .. after i made the application that works fine by the way , i discovered that there are fields and probably even tables to be added to the database(an oracle 11g instance database)..so my questions are the following:
if i create the classes and update the existing .. will it be written directly in the database?
if not is there any way to do it because i dont think a direct update in the database will be a good idea ..
thank you in advance ..
If I understand correctly, you want to know whether the database schema can be created/updated automatically from your #Entity classes, and how to enable/disable such creation. Yes, it's possible by using some property. The name of the property would depend on your project kind. For example, in a default Spring Boot application, you can have
spring.jpa.hibernate.ddl-auto: update
in application.properties. The value update above will have the schema automatically created on first run and then updated on subsequently. validate instead of update won't alter the schema, but just validate it.
This stackoverflow post lists the possible values and their behaviour.

Sharing a database between two ASP.NET MVC 3 applications on Azure

(I had a hard time titling the question so feel free to suggest edits)
Here's the situation: we have just started building a system which is comprised of two integrated MVC 3 web applications running on Azure with a shared AzureSQL database. There are many reasons for running two apps instead of one and I'd rather not get into that...
Originally, database was created code-first from the MVC application "A". 75% of entities from all created will be relevant to application "B" plus application "B" will need a few entities specific to it.
Currently, the entities-defining classes have been extracted into a class library so within the application "A" solution to allow for reuse in application "B". But I am still unsure how to go about adding entities required for application "B"...
The question is: what is the best way to manage the database development/management in this situation? Specifically, where should the definition of entities be? Should we just have a separate db project defining the database and work db-first? (with this option being my preferred at this stage).
Since both of the devs (me and the other dev) working on this are new to MVC and EF, any advice would be much appreciated.
Without seeing what you have its not entirely mapping here in my brain - but I think I may have an idea on this.
Can you create an additional projects containing your models (data access layer) that has your entity framework edmx (or code first) and poco templates installed. This project will be shared by both applications - ie both projects get this assembly and both have the ef connect string in their web.configs.
Another approach is to put all code first into a single project (whatever.domain, whatever.models) etc. Your mapping code then goes into your DataAccess project
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Conventions.Remove();
modelBuilder.Configurations.Add(new CustomerMap());
...
}
You now have shared poco classes and a single data access layer.
Some treat their poco classes as their domain objects (theres no problem with this) and their business logic goes in the poco classes. This is fine as long as your poco objects themselves remain persistent ignorant and ideally you don't want to reference implementation specific components in your poco classes. For a good writeup here see:
POCO - if POCO means pure .net class with only properties, where i can write validations in MVC
Personally I like db first and then reverse engineer it using the EF power tools to have a code first model as if you ever want to integration test it, you can simply create the db for your integration tests and remove it when done.

Resources