JPA - Mapping a table in a specific database and schema.

[Former Member]

Hello,

I am using NetWeaver 7.2 and SAP native libraries to map tables with JPA.

The database engine is a MS SQL Server, which has inumerous Databases (catalogs) running in the engine.

When mapping the table the "catalog" attribute of "@Table" annotation (which corresponds to the database name) is not supported for the JPA provided by SAP. Instead of that i tried declaring the name of the table in the following way: @Table(name=database.schema.table). Example: @Table(name=mydb.dbo.User).

The above code worked well in others JPA frameworks (like Hibernate), however the SAP JPA Engine wasnt able to find my table.

If I create the datasource specific for each database I can map entities only by providing the table name, however I wouldnt like to create a specific PersistenceUnit with its own Datasource for each Database (catalog). The JPA specification handle this, so I assume the SAP engine should be able to follow the specification.

Anyone that can help with my issue?

Thanks.

[Former Member]

Thanks Rolf,

We will not be able to change the 3rd party JPA engine at this moment, so we'll just create additional data sources for now.

[rolf_paulsen]

Hi,

unfortunately, you are right:

Like with loadtime class transformation, e.g. for lazy loading of XToOne relations, SAP did not do their Java EE implementation completely.

As you say, the Java EE 3.0 / JPA 1.0 persistence spec without any doubt tells that every Java EE application server like SAP NetWeaver Java and its JPA-provider SAP JPA must implement the catalog attribute both in XML-descriptors and in annotations of entities, table generators, and join tables. There is no word in the spec that implementation of "catalog" is optional for a JPA provider.

Result: SAP JPA is not spec compliant, the unsupported catalog attribute is a software bug (product fault) and you may post an OSS for it.

Concering spec conform loadtime class transormation for 3rd party persistence providers, they are working on a solution. It has been not easy to get there, you must be patient and insistent. (Even for shortcomings in spec confirmity, they want a business case.)

If you have a chance to switch over to another provider, e.g. eclipselink, you should try it.

Regards,

Rolf