We Keep Coding

Is it possible to assign multiple ORM configurations to a Java Model?

We have this situation:
One backend written with Spring.
One native Android app.
They share many of the models.
What it has been done is writing models in a package on the backend and then export it as jar in android.
On android we are using OrmLite to interact with these models on the DB. The models have their proper annotations to achieve this. On the backend we basically write raw crud queries for each model, this is getting crazy as every time we add a field we need to update all the relevant queries.
What we would like to achieve is to use another orm on the server. The problem is that server and tablet for old bad design choices have different column and table names even though the models are the same. Renaming columns and tables cannot be done because it involves too much work.
We need to get things smarter, but we would also like to avoid duplicating the models just to remap the models to a different database schema.
Do you have any idea on a smart way on how to achieve this?

Unfortunately, "Renaming columns and tables cannot be done because it involves too much work" is the best solution to have consistent and managebale code base in the long term.
For the short term, what could be smart is to use XML based configuration on the server and stick to annotations for the tablet app.
Update
You want to look at JPA specification, it defines the persistence mechanism in java. There are multiple implementation providers for it, here is the list for providers of the specificaions latest version.
I only have experience with Hibernate ORM which along with its native API also provides implementation for JPA. It has XML based configuration option in addition to annotations. You will have evaluate which provider suits your requirment.
If the annotation of ORMlite differ from JPA then you can even use the JPA annotation in the entity classes besides the ORMLite annotation. But beware this will make your entity model classes messy and you will need both your selected JPA implemantion library and ORMLite library on the classpath of entity model.

Embedding database operations in our framework

We started writing a Java Framework for our company. But we don't have enough experience about Java. We decided to use JPA framework for database CRUD operations.
What do you suggest about that:
about defining persistence.xml. We search creating dynamic
EntityManager and found some documents but we don't know that is
it best way.
Is it a good way that create a layer over JPA base db operations?
(for example CRUD methods.)
How can we do calling JPA CRUD methods from my CRUD methods in
framework?
We will use this framework for desktop and web applications. Is
deployment a problem for us.
Do we have to use EJB?
Is there alternative to JPA which you suggest? (example: ADF,JDBC)
Thanks

It highly depends on your requirements and what you want to do with your "framework". I do not know enough of your project to give you a real advise, but here are some thoughts:
What do you mean with "framework"? Are you developing a library which other people should use? What should be the purpose of your framework? Is it a data access layer for some of your company data? If so: JPA is a kind of a standard and might be a good fit since it is widely used. If other people should use your "framework" it is good to use something which is standard and used in many other applications and tools.
Do you really need a data access layer on the desktop? Do you have a rich client? It is no problem to just "deploy" the application to the desktop, but a data access layer must always be configured and (maybe) updated. And that's where the pain begins when you use a rich client. Users must configure a database, the database must be installed or accessible remote and the version of the client must match the version of the database. Sooner or later this will hit you.
What else have you considered already? What about a ORM? Hibernate might by a good and popular fit. Also eBeans which is used in Play! is very cool. If you make a CRUD applications, frameworks like eBeans are doing most of the work out-of-the-box for you. You create a model (just POJOs + annotations) and the frameworks provides the complete data access layer (including the database setup).

How does Spring Data (JPA) relate to JPA persistence providers?

I'm trying to wrap my head around JPA and have learned quite a bit. JPA is a java specification and providers implement this spec. I Understand that part.
What I don't understand is how Spring Data comes into the picture. Is Spring Data also a provider like Hibernate or OpenJPA? If not, what is it? How does Spring Data "make things easier"?

The Spring Data project in general is an umbrella project with the following mission statement:
… provide a familiar and consistent Spring-based programming model while retaining store-specific features and capabilities.
So we approach the persistence space in general not only relational data access through JPA. The important piece here is two fold:
Programming model instead of generic API
Support for store specific features
As the data access space is so diverse these days, trying to approach all of the stores with a single unifying API is doomed to fail. You'd end up with a least common denominator that hides away the store specific parts - in times where you selectively choose a particular store because of it's specifics. Abstracting those away totally subverts this. Especially trying to use JPA is wrong in our opinion as it's deeply tied to relational concepts (#Table, joins, transactions) by definition.
Still, you don't want to work with completely different APIs, don't wanna be lost in store differences if you work with multiple ones or switch from one project to another. Spring has traditionally helped in that regard by embracing a consistent programming model, that features abstractions that work the same way but are still specific to a particular technology. For example, JDBC and JMS are completely different technologies. Spring offers both a JdbcTemplate as well as a JmsTemplate that cover the same responsibilities (resource management and exception translation) and lower the learning curve when moving from working with JDBC to JMS or vice versa.
Spring Data picks up on that by exposing store-specific functionality through abstractions that Spring developers know. I already mentioned the template, but that also includes general configuration mechanisms (XML namespaces, using DI and AOP etc.).
Repositories
The very top layer of this programming model is the repository abstraction. In its core, it significantly simplifies the development of data access layers by letting you avoid to write more implementation code than strictly necessary. It provides CRUD functionality out of the box, pagination as well as declarative query methods.
Assume a Customer domain class. Enabling persistence for it is just a matter of declaring a repository interface like this:
interface CustomerRepository extends PagingAndSortingRepository<Customer, Long> {
List<Customer> findByLastnameContaining(String lastname);
}
Now it's a matter of configuration (and domain class mapping) to be able to create an instance of this interface and use it from a client. PagingAndSortingRepository includes basic CRUD functionality as well as stuff like Page<Customer> findAll(Pageable pageable) (so page-by-page access). As you can see, we also support a query derivation mechanism to avoid needing to write any implementation code for simply queries. For more complex ones, we allow the manual declaration (e.g. using #Query on the method) or even the manual implementation if necessary.
A neat side-effect here is, that by a flip-switch in the configuration you could use the same repository interface to persist Customer instances into a MongoDB. That doesn't mean we recommend to blindly move from one store to another as the stores usually require the data model to be adapted to work efficiently. However it allows developers to quickly switch between projects working with different stores as the repositories just work the same way (implementing the programming model over common API approach).
JPA specifics
Spring Data JPA is actually a thin layer implementing the repository abstraction plus a few other bells and whistles. So we're not replacing persistence providers but actually leverage them through the API, even mitigating some of the quirks and differences between individual JPA providers.

Think of Spring Data as a way to support JPA and many other persistence models in a manner that is transparent to your own code. Spring Data makes it easier for you to manipulate more types of data source systems in a unified interface. Without Spring Data, you would need to introduce more adapters in your code, each time you would have to deal with extra logic.

spring-data JPA is not a JPA provider. It is a library / framework that adds an extra layer of abstraction on the top of our JPA provider(Hibernate/TopLink). If you are using Spring Data in your project, you are not going to write most of the low level data access operations like writing SQL query, DAO classes etc.
But you must have a JPA-Provider (Hibernate, Toplink etc) to implement spring-data-jpa.

Migration from one ORM to another

Here is my problem. I am using Play2 Framework right now and it's providing me with Ebean as my default ORM product. I know Java fairly well and decide to write a website using Java, but I also want to learn Go, and ultimately change my websites' backend codes to Go (Go's framework Revel). I know my data will still be there, but I will have to use a different ORM product to rewrite all the models. Will this cause a problem even though I maintain the same exact database structure?

It depends on what's your definition of 'problem'.
ORM frameworks provides facility to map database information (relational data) into OOP object. Variation exists between ORM frameworks as to what DBMS they support, default naming rule when mapping table/column name to class/field, update cascading, transaction management, cache management, SQL translation etc.
You can keep your database schema and map it using different ORM, above is just some problem you might / not encounter along the way

Is there a good generic pattern for data store queries that hide vendor specific logic?

I'm trying to find a good way to implement a generic search API in Java that will allow my users to search the backend repository without needing to know what that backend technology is, and so that if in the future we switch vendors I can reimplement the underlying logic without needing to recode the API. The repository underneath could be a relational database or a document store like SOLR, CouchDB, MongoDB, etc... It would need to support all the typical search requirements such as wildcards, ranges, bitwise operators, and so on.
Are there any standard ways of approaching this problem?
Would JPA be my best bet? Would it do everything I need it for, including non-relational databases?
Thanks in advance!

What you need is a ORM framework like Hibernate, if you go for JPA, you need to re-invent a lot of wheel.
using Hibernate you can write the business logic for searching the backend database or repository without vendor specific implementation, and if later you need to change the backend, you can do it without affecting your existing business code implementation.
I would advice you to check the hibernate documentation for further reference

The Spring Data umbrella of projects provides a nice DAO abstraction named CrudRepository. I believe most of the sub-projects (JPA, MongoDB, etc.) provide some implementations of it.

JPA would be one of a number of implementations you would use to map your relational database to objects. It would not protect you from database changes.
I think you're looking for the DAO Pattern. What I'm doing is as follows:
Create an interface for each DAO
Create a higher level DAO implementation that simply calls my actual database specific implementation
Wire the higher level DAO implementation to the database specific implementation with Spring.
This way, no code anywhere touches database specific implementation. The connections are formed only in XML.

JPA is designed around RDBMS ... only. Using it for other types of datastores makes little sense since things likes its query language leak SQL syntax. JDO is designed for datastore agnoticity, and provides persistence to many datastores using its implementations such as DataNucleus, though not all of those that you mention.

JPA is designed around RDBMS, Hibernate is also designed for RDBMS. There are few implementations of JPA which support no-sql. Similar projects are built around hibernate to support no-sql databases. However the API itself is tuned for RDBMS.
Implemeting a DAO patterns would require you to write your own query api. Later extend the implementation when ever your data store changes.
JDO and DataNucleus is ground up designed for heterogeneous data stores. Already has support for a dozen stores ,plus RDBMS. Beauty is that the query api remains constant across the stores. JDO allows you to work with domain model and leave the storage details to implementations like DataNucleus.
Hence I suggest JDO api with datanucleus.
The below link gives list data stores and f features already available in DataNucleus
http://www.datanucleus.org/products/accessplatform_3_0/datastore_features.html