We Keep Coding

Java ORM without Mapping

Working with Hibernate, I noticed that all of the Java objects going into persistence are defined in a mapping file. Is there a way to only depend on the annotations instead of a separate .xml for this? At the time of creation, we do not know what the object that is to be persisted contains. We know it is primitive data types, Strings, ints, floats/doubles, but we do not know how many of each field the object may contain until the same time it needs to have a table created for it to be entered into the db.
Note that Hibernate is just the first ORM solution that I've looked at. I am not tied to it if there is another ORM solution that solves this problem.

I think in your use case, you can use Dozer mapping for managing beans without having explicit definitions of class files and this can ben loaded at runtime using spring annotatons dependency injection.

You may look into JDX ORM for Java. The mapping is defined declaratively in a text file but just a minimal specification is needed for each class - its name and the names of the primary key attributes. Other attributes are automatically picked up by JDX. So you may continue to modify your class without making any further changes to its mapping specification. Disclaimer: I am the architect of JDX ORM.

How do I Implement this design to remove code repetition

My application has about 50 entities that are displayed in grid format in the UI. All 50 entities have CRUD operations. Most of the operations have the standard flow
ie. for get, read entities from repository, convert to DTO and return a list of DTO's.
for create/update/delete - get DTO's - convert to entities, use repository to create/update/delete on DB, return updated DTOs
Mind you that for SOME entities, there are also some entity specific operations that have to be done.
Currently, we have a get/create/update/delete method for all our entities like
getProducts
createProducts
updateProducts
getCustomers
createCustomers
updateCustomers
in each of these methods, we use the Product/Customer repository to perform the CRUD operation AFTER conversion from entity -> dto and vice versa.
I feel there is a lot of code repetition and there must be a way by which we can remove so many of these methods.
Can i use some pattern (COMMAND PATTERN) to get away with code repetition?

Have a look at the Spring Data JPA or here project. It does away with boilerplate code for DAO.
I believe it basically uses AOP to interpret calls like
findByNameandpassword (String name,String passwd)
to do a query based upon the parameters passed in selecting the fields in the method name (only an interface).
Being a spring project it has very minimal requirements for spring libraries.

Basically, you have 2 ways to do this.
First way: Code generation
Write a class that can generate the code given a database schema.
Note that this you will create basic classes for each entity.
If you have custom code (code specific to certain entities) you can put that in subclasses so that it doesn't get overwritten when you regenerate the basic classes.
Object instatiation should be via Factory methods so that the correct subclass is used.
Make sure you add comments in the generated code that clearly states that the code is generated automatically (so that people don't start editing them directly).
Second way: Reflection
This solution, while being more elegant, is also more complex.
Instead of generating one basic class for each entity you have one basic class that can handle any entity. The class would be using reflection to access the DTO:s.
If you have custom code (code specific to certain entities) you can put that in other classes. These other classes would be injected into the generic class.
Using reflection would require a strict naming policy on your DTO:s.
Conclusion
I have been in a project using the first method in a migration project to generate DTO classes for the service interface between the new application server (running java) and the fat clients and it worked quite well. We had more than 100 generated DTO classes. I am aware that what you are attempting is slighty different. Editing database records is a generic problem (all projects need it) but there aren't (m)any frameworks for it.
I have been thinking about creating a generic tool or framework for it but I have never gotten around to it.

POJO or DTO approach

I am developing a new web application with Struts2, Spring and Hibernate as its core building blocks.
We have created POJO classes with respect to hibernate mapping files.There will be some inputs from users which needs to be updated in to the underlying database
e.g registration or updation.
We have few option like creating new POJO/DTO for action classes which will be filled by the Struts2 and than we can transfer them to the service layer where we can convert those DTO to the respected hibernate POJO else we can expose same POJO to struts2 so that the framework can fill them with the user input and we need not to do the work for conversion and creating extra set of classes.
Application will be not big in size and will have a medium size application tag.
My question is what is the best way to transfer this user input to underlying hibernate layer to perform data base specific work.
Thanks in advance

I'd prefer the "DTO" approach in this case since you then can validate the input first and trigger updates only when wanted.
However, you could use detached entities as DTOs and reattach them when you want to create or update them. If you don't want the web part of your application to depend on Hibernate and/or JPA you might need to create another set of classes (unless you don't use a single annotation).

You'll get both answers on this.
With Struts 2 I tend to use normal S2 action properties to gather form values/etc. and use BeanUtils to copy them to the Hibernate objects. The problem with exposing the Hibernate objects to the form, like with ModelDriven etc. is that you need to define whitelists/blacklists if you have columns that should not be set directly by the user. (Or handle the problem in a different way.)
That said, I'm not fundamentally opposed to the idea like a lot of people are, and they're arguably correct.

How do I use JPA to make library objects database persistent?

I've been using JPA on a small application I've been working on. I now have a need to create a data structure that basically extends or encapsulates a graph data structure object. The graph will need to be persisted to the database.
For persistable objects I write myself, it is very easy to extend them and have the extending classes also persist easily. However, I now find myself wanting to use a library of graph related objects (Nodes, edges, simple graphs, directed graphs, etc) in the JGrahpT library. However, the base classes are not defined as persistable JPA objects, so I'm not sure how to get those classes to save into the database.
I have a couple ideas and I'd like some feedback.
Option 1)
Use the decorator design pattern as I go along to add persistence to an extended version of the base class.
Challenges:
-- How do I persist the private fields of a class that are needed for it to be in the correct state? Do I just extend the class add an ID field, and mark it as persistable? How will JPA get the necessary fields from the parent class? (Something like ruby's runtime class modification would be awesome here)
-- There is a class hierarchy (Abstract Graph, Directed Graph, Directed Weighted Graph, etc.). If I extend to get persistence, extending classes still won't have the common parent class. How do I resolve this? (Again, Something like ruby's runtime class modification would be awesome here)
Option 2) Copy paste the entire code base. Modify the source code of each file to make it JPA compatible.
-- obviously this is a lot of work
I'm sure there are other options.. What have you got for me SO???

Do the base classes follow the JavaBeans naming conventions? If so you should be able to map them using the XML syntax of JPA.
This is documented in Chapter 10 of the specification:
The XML descriptor is intended to
serve as both an alternative to and an
overriding mechanism for Java language
metadata annotations.
This XML file is usually called orm.xml. The schema is available online

Your options with JPA annotations seem pretty limited if you're working with a pre-existing library. One alternative would be to use something like Hibernate XML mapping files instead of JPA. You can declare your mappings outside of the classes themselves. Private fields aren't an issue, Hibernate will ignore access modifiers via reflection. However, even this may end up being more trouble than its worth depending on the internal logic of the code (Hibernate's use of special collections and proxies for instance, will get you in hot water if the classes directly access some of their properties instead of using getter methods internally).
On the other hand, I don't see why you'd consider option 2 'a lot of work'. Creating a ORM mapping isn't really a no brainer task no matter how you go about it, and personally I'd consider option 2 probably the least effort approach. You'd probably want to maintain it as a patch file so you could keep up with updates to the library, rather than just forking.

Database framework developing

I'm developing (another) java web framework for personal use, and in addition to that I also want to develop somekind of persistence framework.
I have already developed and engine that in order to access the table, you must only extend a class and create your fields with the same type and name of those in the table. Ex:
private int id;
private String nome;
So you only need now to build the query and execute. The engine put the values on the right fields.
Recently I've had a quite good experience with Django, wich in order to update, create and filter the table you just need to call .save(), .create(field1=field, field2=213) and, .filter(filterfield=value).
I want to build this to, but I am having some trouble, because the extending class would actually have to write more, fact that I don't want to force. I have had the idea to the extending class write an enum implementing an Interface. So the super class get those fields, along with a private HashMap (the key is the enum) and keep the values, so the client just calls:
String nome = Usuarios.get(Usuarios.fields.name);
To retrieve the value.
Usuarios.update(new Pair(Usuarios.fields.name, "José Leal"), new Pair(Usuarios.fields.sobrenome, "Domingues"));
To update and so on.
Anyone have a better idea? I also use velocity framework, so I would like my field to be accessible by its getter.
ps: I know the existence of hibernate and etc.

I would suggest that you not force users to extend one of your own classes for their model objects. This locks them out of extending their own classes, and makes them more vulnerable to API changes you might make later.
Seeing as javax.persistence already defines annotations that can be used for mapping properties to a database, I'd suggest instead that you let the users make POJOs for their model objects with annotated properties. That way, along with the other mentioned benefits, you're following an already established standard and thereby lowering the barrier to entry for your users.