TopLink support DB2/OS390 - TopLink/JPA

Does TopLink support connecting to DB2/OS390? If so, is it with the standard DB2 selection in Workbench, or will another method be required?
Thanks

Related

How to obtain the actual database type (SQL type) of  a database column?

How do I obtain the actual database type (SQL type) of a database column? It seems that the database column type information is not available in the Project descriptor.
I know that in general you wont have the need to know the type information, (as the type conversion is transparently done by the Toplink API), but we have such a need right now. We are planning to use the Project descriptor with our custom persistence framework instead of Toplink API for now and use the Toplink API in the future.
Thanks
Jay 
Jay,
TopLink does not hold this information in its mapping metadata. It is used during the mapping process to make a best guess at the Java types needed when generating a model but not at runtime. Different databases and JDBC drivers return different types so there is little value in storing this without coupling the runtime to a specific driver.
It would be possible to retrieve this information at system startup and store it as additional properties on your descriptor and mappings. I would use a session event listener postLogin to retrieve this information and make it available. That way if you ever upgrade your JDBC driver it will simply adjust and capture the new types.
Doug 
Jay,
What version of TopLink are you developing against?
Doug 
Doug,
Thanks for your idea.
The version we are developing against is 9.0.4
-Jay

Toplink 11 & JPA: advisable way going forward?

Hi,
We're considering the Toplink configuration choices of a new major information system.
This system will not be in production for at least a year or more.
I think we have a few options:
- keep on using Toplink Workbench ORM 10.1.3
- start using Toplink JPA 11. I get the impression that this is the preferred way forward for J2EE applications on Oracle AS. It makes me wonder whether all Toplink specific value added functionality, like historical queries f.i., will be available using this annotation based approach. Another concern obviously is how many problems we'll encounter because the product is in preview. Is it suitable for development yet? Will there be regular preview updates? Will Toplink 11 work under OC4J 10.1.3?
- start using Toplink JPA 10.1.3. If I understand the documentation correctly this is an implementation of a preview of the JPA/EJB spec and is not recommended.
- start using Toplink Essentials. I get the impression that this precludes us from using Oracle Toplink specific functionality like historical queries.
Thanks for your advice.
Regards,
Joost 
If your system will not be in production for a year or more, I would recommend using the 11g preview. There should be a second preview available in the coming months. In theory you should be able to use TopLink 11 in 10.1.3, but I have never tried this personally, so I'm not certain it will work, you may need to use some MacGyvering, or use the OC4J 11g preview as well.
---
James Sutherland 
Thanks for your reply James.
I've also seen your What is best...TopLink or JPA...??....
Do I understand correctly that all Toplink specific functionality is available when using Toplink 11 JPA? Can you give me a clue how this will work?
As you can imagine it's much harder organisationally to migrate server infrastructure to Oracle AS 11 then that it is to migrate the Toplink library used by an application. What is Oracle's policy in that respect? 
Do I understand correctly that all Toplink specific functionality is available when using Toplink 11 JPA? Can you give me a clue how this will work? TopLink exposes its' functionality beyond the JPA specification in several ways:
- Extended annotations are provided in the oracle.toplink.annotations package. These allow you to configure functionality like caching, locking and additional mappings not included in the JPA spec.
- The TopLink sessions.xml and project.xml files can be used in place of the JPA orm.xml (or annotations), this gives you access to using the TopLink Mapping Workbench and all of TopLink's mapping functionality. You just need to set the sessions XML property in your JPA persistence.xml to do this.
- You can customize your JPA generated TopLink descriptors or session using the DescriptorCustomizer or SessionCustomizer from your persistence.xml or using the #Customizer annotation.
- You can cast your JPA EntityManager to the TopLink EntityManager interface, which exposes additional API. The JPA Query can also be cast to the TopLink Query interface. You can also access the underlying TopLink Session and DatabaseQuery from these to make use of any TopLink functionality that is not exposed.
As you can imagine it's much harder organizationally to migrate server infrastructure to Oracle AS 11 then that it is to migrate the TopLink library used by an application. What is Oracle's policy in that respect? Oracle TopLink has always done its best to be portable across ALL application servers. It is our goal that TopLink 11g could be used in OC4J 10.1.3, and it should work, but I have not tested this myself.
---
James Sutherland 
Just what I wanted to know. Thanks James.

Migration from Toplink to Toplink JPA

Hi –
I need some help in migrating my current code written using Toplink API (oracle.*..) to JPA compliant (javax.persistence.*, Toplink Essentials).
Can you suggest ways to make this easier?
Some of Toplink features used by me -
1.     I have models which extensively use indirection (ValueHolderInterface) for one to many mapping.
2.     I have a session.xml and project xml file.
3.     I have configured to use external connection pool using weblogic connection pool
4.     I have used optimistic locking.
5.     I have made some caching optimization.
6.     Most of these I did using Toplink Workbench.
I need to migrate to JPA compiliant code without missing out any of the above.
It would be great if you could suggest the alternatives of the above in JPA (Toplink Essentials).
Thanks.
Anand 
Anand,
1.     I have models which extensively use indirection
(ValueHolderInterface) for one to many mapping.When using JPA you can have #oneToOne and #ManyToOne relationships be lazy loaded without having to code the ValueHolder into the domain model. Instead TopLink makes use of byte code weaving to add the ValueHolder transparently into your code. This weaving happens automatically in the container but requires a -javaagent: to work in JavaSE or Spring.
2.     I have a session.xml and project xml file.This is basically replaced by JPA's persistence.xml file and TopLink's persistence unit properties.
3.     I have configured to use external connection pool
using weblogic connection poolThis can be done using JTA data source configuration in the persistence.xml configuration file.
4.     I have used optimistic locking.Assuming you are using a single column numeric or timestamp field you can use JPA's #Version configuration to enable TopLink's optimistic locking.
5.     I have made some caching optimization.These are supported using persistence unit properties in the persistence.xml file.
In Oracle TopLink and EclipseLink we have added #Cache annotations to enable configuring these on the entities instead of in XML.
6.     Most of these I did using Toplink Workbench.
I need to migrate to JPA compiliant code without
missing out any of the above.
It would be great if you could suggest the
alternatives of the above in JPA (Toplink
Essentials).With JPA addressing persistence using annotations and/or XML you will need to migrate from using the workbench to either use an IDE that supports JPA. We have great support added in both JDeveloper and the Eclipse IDE.
Some Links:
- TopLink Essentials JPA Extensions
- Oracle TopLink 11gR1 (tech preview 3) JPA Extensions
- EclipseLink JPA Extensions
Doug

Native Toplink to EclipseLink to JPA - Migration Best Practice

I am currently looking at the future technical stack of our developments, and would appreciate any advise concerning best practice migration paths.
Our current platform is as follows:
Oracle 10g AS -> Toplink 10g -> Spring 2.5.x
We have (approx.) 100 seperate Toplink Mapping Workbench projects (we have one per DDD Aggregate object in effect) and therefore 100 Repositories (or DAOs), some using Toplink code (e.g. Expression Builder, Class Extractors etc) on top of the mappings to support Object to RDB (legacy) mismatch.
Future platform is:
Oracle 11g AS -> EclipseLink -> Spring 3.x
Migration issues are as follows:
Spring 3.x does not provide any Native Toplink ORM support
Spring 2.5.x requires Toplink 10g to provide Native Toplink ORM support
My current plan is as follows:
1. Migrate Code and Mappings to use EclipseLink (as per Link:[http://wiki.eclipse.org/EclipseLink/Examples/MigratingFromOracleTopLink])
2. Temporarily re-implement the Spring 2.5.x ->Toplink 10g support code to use EclipseLink (e.g. TopLinkDaoSupport etc) to enable testing of this step.
3. Refactor all Repositories/DAOs and Support code to use JPA engine (i.e. Entity Manager etc.)
4. Move to Spring 3.x
5. Move to 11g (when available!)
Step 2 is only required to enable testing of the mapping changes, without changing to use the JPA engine.
Step 3 will only work if my understanding of the following statement is correct (i.e. I can use the JPA engine to run native Toplink mappings and associated code):
Quote:"Deployment XML files from Oracle TopLink 10.1.3 and above can be read by EclipseLink."
Speciifc questions are:
Is my understanding correct regarding the above?
Is there any other path to achieve the goal of using 11g, EclipseLink (and Spring 3.x)?
Is this achieveable without refactoring all XML mappings from Native -> JPA?
Many thanks for any assistance.
Marc 
It is possible to use the native/MW TopLink/EclipseLink deployment xml files with JPA in EclipseLink, this is correct. You just need to pass a persistence property giving your sessions.xml file location. The native API is also still supported in EclipseLink.
---
James : http://www.eclipselink.org 
Is it possible to migrate class by class mappings to JPA annotation, while the others still use the proprietary TopLink XML descriptors?
You said "need to pass a persistence property". Any keyword I can use to search for it? Or an example?

TopLink support DB2/OS390

Does TopLink support connecting to DB2/OS390? If so, is it with the standard DB2 selection in Workbench, or will another method be required?
Thanks 
Hi,
In addition to selecting DB2 in the workbench, you will need a valid JDBC driver.
Ensure that the path to your JDBC driver classes are included in your CLASSPATH.
TopLink can communicate with any relational database which has a JDBC-compliant driver available such as Oracle, DB2, Sybase, SQL Server, Informix, Cloudscape, and Access. TopLink supports both the JDBC 1.x and 2.0 standards.
Raanan. 
Sorry, meant to say DB2 on AS/400. 
Sorry, meant to say DB2 on AS/400. We do have a number of customers using TopLink on AS/400 with DB2. I do recall experiencing an issue with the JDBC driver IBM provided though. It would not properly report the meta-data information the Mapping Workbench uses to import schemas. To work around this, we manually entered the table information in one case, and in another case we exported the schema to another platform and imported it through a better JDBC driver. I'm sorry I can't confirm which specifric versions this was for. It is a documented limitation of the IBM JDBC driver however. Other than that, we had no problems at all.
- Don

Categories

Resources