We intend to provide Linux and Solaris version in the future.

You need a license key to use ObjectDRIVER.

Let %ODPATH% be the root directory where you installed ObjectDRIVER. If you installed the Java version of ObjectDRIVER go to the %ODPATH%\Bin\RegisterJava directory. If you installed the C++ version, go to the %ODPATH%\Bin\RegisterCpp directory. Launch the Register application. This Register application will generate a file which magic extension is ".key". Send it to register@infobjects.com. Infobjects will send you by e-mail a license key. Append it to your %ODPATH%\system\license.key file.

ObjectDRIVER is now ready to use! Configure the appropriate ODBC data source names to try the ObjectDRIVER Console application or run the examples. They are in the %ODPATH%\Examples directory. See this booklet for more information.

Maybe did you have a trial license key, and trial time elapsed.
Contact us to obtain a renewal for your license.

You might also have moved ObjectDRIVER on your disk. ObjectDRIVER is not supposed to be moved after having been installed. Replace it on its original location or contact us to get a new appropriate license.

Object-relational mappings are not defined programmatically. They are defined outside the Java and C++ applications. Mappings are defined in a declarative manner, in files without any single line of code. Basically, they are class declarations interlaced with mapping declarations. They are contained in text files which must be in the %ODPATH%\schemas directory. A mapping is globally described in two files: a relational file, which contains the description of the relational database schema, and a second one, that contains the correspondence schema, i.e. all of the mapping rationale.

If the business logic of your application does not require it, it is useless.

ObjectDRIVER can transparently deal with primary keys, even generating them when needed. Mapping primary keys only to be able to query objects is most of the time useless. ObjectDRIVER provides a powerful query language, OQL, that lets you query objects discriminating them on their properties.

Yes.

However be careful to generate correct primary keys when storing new objects.

ObjectDRIVER does not allow to query mappings. It allows to query virtual object-oriented databases that are designed by mappings. So you have to design your own virtual object-oriented databases.

Luckily, when a mapping has been designed, nearly all the job has been done. You just have to choose a name for your new virtual OODB, let’s say MyOODB, and states that MyOODB is a virtual object-oriented database that is designed by the correspondence schema MyCorrespondenceSchema.txt, on top of the actual Oracle database MyOracle which schema has been described in the MyOracleSchema.txt file. This must be stated in the ObjectDRIVER XML system file %ODPATH%\system\schemas.xml.

Then, in the ObjectDRIVER Console application, or in your Java or C++ application, you can immediately open the MyOODB virtual object-oriented database. The use of the associated correspondence schema is fully transparent.

The hint is not to try to connect to the RDBMS but to the virtual OODBMS. We mean: you can always connect directly to your RDBMS, besides ObjectDRIVER, from your Java or C++ application, using JDBC, ODBC or any connectivity tool –your RDBMS does not disappear. But, after all, you are using ObjectDRIVER to query a virtual object-oriented database, not a RDB. So, logically, you have to connect to a virtual object-oriented database management system: ObjectDRIVER.

However your RDBMS users are not automatically promoted to ObjectDRIVER users. So you (or your DBA) must declare an ObjectDRIVER user and associate her or him to the appropriate RDBMS user. In other words, you, or your DBA, must state that the ObjectDRIVER user ObjectScott is a close friend of the Oracle user Scott. This can be done with the ObjectDRIVER’s ODAdmin application. Then, at runtime, you can connect to ObjectDRIVER as ObjectScott, and, Scott, will be transparently connected to your RDBMS.

Of course, you won’t be able, through ObjectDRIVER, to connect as Scott if you do not have the rights to. There is also a frequently asked question on security.

The answer is very likely to be no. If you have declared a virtual object-oriented database in the %ODPATH%\system\schemas.xml file, it is completely useless. You just have to open the virtual OODB.

The only use of explicit loading is to dynamically declare at runtime a new virtual object-oriented database that could not exist when the application has been run.

ObjectDRIVER has a security policy that is at least equal to the ones of the underlying operating system and the underlying relational database management system.

OQL (Object Query Language) is the ODMG query language. It is designed to query object bases. It is very close to SQL. It is a kind of SQL that queries sets of objects, discriminating on object properties. SQL users get very quickly familiar with OQL.

For instance, assuming that a class of employees is designed as

class Employee {
String name;
long salary;
}

The OQL query below retrieves all the employee names whose salary is higher than 2000.:

select e.name from Employee e where e.salary > 2000.

Set the option.messages.trace option to 3, or higher, in the %ODPATH%\system\config.xml ObjectDRIVER’s system file.

Yes. With ObjectDRIVER there is no need of conversion between raw data and objects. You query classes; you retrieve objects.

For instance, when fired, the OQL query below that is meant to retrieve all of the employee instances which salary attribute value is greater than 2000., will bring back a set of objects instances of the class Employee.

select e from Employee e where e.salary > 2000.

ObjectDRIVER transparently generates the appropriate SQL queries, sends them to the underlying relational database, computes the received raw data and creates the new objects.

Simply state them as persistent. They will be stored at transaction commit. No generation of raw data is required.

Do you need the options.dataviews.object.default.transactions.flush.select.before and options.dataviews.object.default.transactions.flush.select.after options to be set to true? These options guarantee that each time you access the underlying DB its content is consistent with its in memory representation.

For example, assume you retrieve an object from the DB, then you modify it, and finally you want to query again the DB. If the new values of your object fit with the last query, but the older ones don’t, and if you have set the options...commit.select.before option to true, this object will be found again. That’s cool, but there is no free lunch.

Exploring a persistent object graph with these options set to true is expensive as regards performances. So each time you can, while the graph of your objects is being explored, we recommend that these options be set to false.

Platform constraints summarized in this other frequently asked question are relevant, even in Java.

No. ObjectDRIVER current release uses ODBC. So you need ODBC drivers to have access to your data sources.

Java packages are supported. You just have to give the complete name of the class in the correspondence schemas.

For instance, assume that one designs the following Java class:

package com.mycompany.myapp;

public class MyClass {
}

Here is the correct declaration of MyClass in the correspondence schema:

class com.mycompany.myapp.MyClass
type Tuple (
)
end;

Moreover the complete name has to be used in OQL queries:

select obj from com.mycompany.myapp.MyClass obj

Names are not persistent in ObjectDRIVER: they do not survive the boundaries of a transaction but, of course, the named objects do. So using the makePersistent behaviour will free you from the burden of choosing a name.

Anyway, remember that the persistence paradigm is persistence by reachability. No need to send the makePersistent message to each object of a tree: just send it to its root, and the whole tree will be stored at commit time. And if your newly created objects are connected by already persistent objects, we do not have to send any makePersistent message.

ObjectDRIVER complies with the ODMG standard. There may be various transactions and various databases, but, in a thread, the last opened database and the last began, or joined, transaction are known. A transaction is begun on the last opened database; a query is executed in the last began or joined transaction.

Yes.

However, semantically, an ObjectDRIVER virtual object transaction can be understood like a Java object referring the persistent objects it manages.

As a matter of fact, even if it is not referred by any object of your application, a persistent object cannot be finalized before the moment when it could be decided that, after all, it should be stored in the underlying database, that is, before the end of the transaction. Of course, after the transaction has finished, this lonely object will disappear when the next garbage collecting occurs.

On the other hand, the end of a transaction cannot imply that the persistent objects it managed be destroyed at once. If transient objects of your application refer to them, they will survive their owning transaction(s). From the point of view of the finished transaction they will be somehow "zombie" objects.

No, although it is generally a very good policy to do so. But ObjectDRIVER does not require you to do so. It can deal with direct slot access. However direct access of attributes of a persistent capable class from a transient class might require additional use of the ObjectDRIVER Java Enhancer. See this other frequently asked question.

No. The ObjectDRIVER Java Enhancer frees you from all of the mechanisms of persistence; it does not free you from the choices that you, and only you, can make: what database to access, when to open a transaction, when to close it, which query to send… The business logic and the persistence logic is up to you; the persistence mechanisms are hidden by the ObjectDRIVER Java Enhancer.

Well, if saving time and significantly reducing the amount of code you have to write is an important thing, you should.

Basically, implementing a transient Java class is not implementing a persistent one. To set it persistence capable, there are additional interfaces to implement, hence some code to add, hollow and regular objects must be distinguished and sometimes converted, etc. This is pure mechanical code, that could be systematically added by a machine. This machine is the ObjectDRIVER Java Enhancer. Using it, you get in a couple of seconds a safe and efficient code that would have taken otherwise hours of development and test.

So what is the section 6.2 of the Java documentation meant for? Mainly letting you see what is behind the scene. And letting advanced users of ObjectDRIVER take the complete control of every and each interaction with ObjectDRIVER.

Well, this might happen. You have to make a choice: developing with or without the ObjectDRIVER Java Enhancer. So we recommend to choose early. In this case, rollback: don’t implement PersistentObject and use again the ObjectDRIVER Java Enhancer.

At least, all of the persistence capable user defined classes.

Now, what about the transient classes that make use of the persistent classes (for instance, the classes implementing the business logic managing the persistent instances)? If these classes only use behaviours of the persistent classes (including getters and setters), you can safely avoid any process on them. But if these classes directly access public or package slots of the persistent classes, bypassing their getters and setters, we recommend to launch the ObjectDRIVER Java Enhancer on them.

Anyway, uselessly using the ObjectDRIVER Java Enhancer is harmless; unduly forgetting classes that should be parsed can lead to exceptions at runtime.

No.

The useJdk12Features option is an option that can be optionally used when you decide not to use the ObjectDRIVER Java Enhancer, not an option that should be used.

Moreover it is definitely irrelevant if you use the ObjectDRIVER Enhancer.

A persistent object is an instance of a persistence-capable class. A persistence-capable class is a Java class that has been processed by the ObjectDRIVER Java Enhancer. This error message means that ObjectDRIVER has been required to manage an object that is not instance of a persistence capable class.

Make sure that you do not try ObjectDRIVER to manage an instance of a semantically transient class, or make sure that all of your user-defined classes have been processed by the ObjectDRIVER Java Enhancer.

The problem may come from the design of the virtual object-oriented database. Run the Console application (%ODPATH%\Bin\Console) and, if possible, try to fire the queries that your application fired. If the same problem happens, start working on the correspondence schema. But if no problem happens, the problem is probably independent of the virtual OODB design, and lays in the Java application.

In any case, do set the option.messages.trace option of the ObjectDRIVER’s system file %ODPATH%\system\config.xml to its higher value, that is, 5 –you can have thus more information on your problem.

Anyway our technical team would be pleased to answer your questions at any time. Note that the option.messages.trace 5 output will be then very helpful for that.

Yes. Setting the end of a bi-directional relationship automatically sets the other end, provided that the appropriate types are used, that is d_Rel_Ref, d_Rel_Set, d_Rel_List, etc.

To fix that, just turn off C++ exception trapping in C++Builder debugger.

Yes. The use of the ODMG Java and C++ API is not mandatory. You can use a C++ lower level API. See this documentation for more information.

ObjectDRIVER can be used from any language provided that this language can interact with C++ code. See this documentation for more information.

We provide one or two year licenses, or licenses with no time limit.