In general, ObjectStore Release 5.1 is drop-in compatible with Release 4. It is, however, not compatible with applications that use Versions or other features eliminated from Release 5. If you are upgrading from Release 3, you must upgrade your databases with Release 4 before using Release 5.

This chapter includes information about changes to Release 5.1 ObjectStore C++ behavior, and specific conditions that apply independent of platform. The information is organized by specific compatibility with earlier releases. Topics covered include

• Compilation Compatibility
• Behavior Compatibility
• Database Compatibility
• Utility Compatibility: ossg
• Changes from the Previous Release
• Documentation Enhancements

Link Compatibility

Drop-In Compatibility

Note: Applications compiled using ObjectStore Release 5.1 are not backward compatible with previous versions of ObjectStore.

Behavior Compatibility

• OS_IMMEDIATE_THRESH environment variable

• OS_MAX_IMMEDIATE_RANGES environment variable

Database Compatibility

PRM format

Server transaction log change

Utility Compatibility: ossg

Object Design recommends that the most portable method of dealing with this is to create a force_vft() function in your executable that will cause the vfts to be instantiated. See Symbols Missing When Linking ObjectStore Applications in ObjectStore Building C++ Interface Applications for more information.

The other (not recommended) way to deal with this is to use the -weak_symbols flag to ossg to revert ossg to ObjectStore Release 5.1 behavior. The -no_weak_symbols flag still exists in ossg but does emit a warning stating that no_weak_symbols is the default behavior.

-weak_symbols Option

In Release 5.1, default behavior has been changed so that weak import references are never used by default. This was done because using weak import references with DLL schema can cause unpredictable effects. The affected platforms are versions of UNIX. If the weak import feature is needed for some reason, you can restore it by using the -weak_symbols command-line argument to ossg.

ossg Limitations

Explicit Template Specializations

ossg does not permit explicit template specializations. For example:

template <class A> class B { ... };
template <> class B<char> { ... };  // not accepted 

Ossg: error message: "<file>":LINE <number>, syntax error on input ">" 

class B<char> { ... }; 
  
 Forward Declarations

Example

template <class A> class B { ... }; 
class D { 
      class B<int>; // or friend class B<int>; 
}; 
class B<int> { ... }; 

Ossg: error message: "<file>":LINE <number> *** Defining a previously 
defined class <class>

Class Declarations in Templates

Class declarations in templates can produce link errors if the class is derived from another class that defines virtual functions. For example:

Example

struct C { virtual void f(){} }; 
template< class T > struct A  { 
      struct B  : public C { ... }; 
}; 

Ossg: ossg does not break but generates incorrect names

class B<char> { ... };

Changes from the Previous Release

os_database::alloc() and os_segment::alloc()

C Library Interface

Persistent Relocation Maps

• objectstore::set_new_dbs_standard_prm_format(osbool)

• objectstore::get_new_dbs_with_standard_prm_format()

• os_database::get_prms_are_in_standard_prm_format()

• os_database::get_prms_are_in_standard_format()

• objectstore::read_counter() and objectstore::unassigned_address_space_counter()

IP Addresses in UNC Pathnames

//198.316.17/top/dbs/db1

Incompatible Changes to os_CString

The following changes were made:

1. The use of a common empty string was eliminated to avoid cross-segment pointers. The default constructor provides each os_CString object with its own empty string.
   
   
2. Like regular CStrings, os_CStrings share data when copied, by default. This can lead to undesirable cross-segment pointers. To avoid this, Object Design recommends that you call os_CString::LockBuffer() on persistent os_CStrings. Copying a transient os_CString to a persistent location, or copying a persistent os_CString from one database to another will copy the data instead of sharing it.
   
   
3. Internal operations on os_CString use _ODI_strlen instead of lstrlen. If a persistent string is not currently mapped into memory, _ODI_strlen causes it to be mapped and returns the correct length, unlike lstrlen, which returns 0.
   
   

For example, the following will work and is the recommended usage:

osbackup -f ./test1.db.back0 -i test1.db.record -l 0 -a test1.db
osbackup -f ./test2.db.back0 -i test2.db.record -l 0 -a test2.db
osbackup -f ./test1.db.back4 -i test1.db.record -l 4 -a test1.db
osbackup -f ./test2.db.back4 -i test2.db.record -l 4 -a test2.db

osbackup -f ./test1.db.back0 -l 0 -a test1.db
osbackup -f ./test2.db.back0 -l 0 -a test2.db
osbackup -f ./test1.db.back4 -l 4 -a test1.db
osbackup -f ./test2.db.back4 -l 4 -a test2.db

Correction to Some Examples in the ObjectStore C++ API User Guide

Using Nonparameterized References

If your compiler does not support class templates, you can use the nonparameterized reference class os_reference. You also should use os_reference if you need a reference to an instance of a built-in type like int or char; the referent type of an os_Reference must be a class.

os_reference is just like os_Reference, except the conversion constructor used is os_reference(void*) instead of os_Reference(T*). In addition, the conversion operator used is operator void*() instead of operator T*(), which means that you should use a cast to pointer-to-referent type when dereferencing an os_reference.

Corrections to Nonparameterized example 1

Here are some examples:

      #include <ostore/ostore.hh>
      #include <stdio.h>
      class employee {

public:
      static os_typespec *get_os_typespec();
      . . . 

int emp_id;
      };
      class part {

public:
      static os_typespec *get_os_typespec();
      . . . 
      os_reference responsible_engineer;
      . . . 
      };
      f() {
      objectstore::initialize();
      static os_database *db1 = os_database::open("/thx/parts");
      static os_database *db2 = os_database::open("/thx/parts");
      OS_BEGIN_TXN(tx1, 0, os_transaction::update)
            part *a_part = new(db1, part::get_os_typespec()) part;
            employee *an_emp = 
                  new(db2, employee::get_os_typespec()) employee;
            a_part->responsible_engineer = an_emp;

            printf("%d\n", 
            (employee*) (a_part->responsible_engineer)->emp_id);

            printf("%d\n", 
                  ((employee*) (void*)
                  (a_part->responsible_engineer))->emp_id);
      OS_END_TXN(tx1)
      db1->close();
      }

      #include <ostore/ostore.hh>
      #include <ostore/coll.hh>
      #include "part.hh"
      main() {
      objectstore::initialize();
      part *a_part; 
      os_database *db1 = os_database::open("/thx/parts");
      os_reference part_set_ref;
      OS_BEGIN_TXN(tx1, 0, os_transaction::update)
            part_set_ref = (os_set*) (
                  db1->find_root("part_set")->get_value()
            ); /* retrieval */
            . . . 
      OS_END_TXN(tx1)
      OS_BEGIN_TXN(tx2, 0, os_transaction::update)

            a_part = (part*) (
                  ((os_set*) (part_set_ref))->query_pick(
                  "part", "part_number==123456", db1
                  )
            ) ; /* OK */

a_part = (part*) (
            ((os_set*)(void*) (part_set_ref))->query_pick(
                  "part", "part_number==123456", db1
            )
            ) ; /* OK */
            . . . 
      OS_END_TXN(tx2)
      db1->close();
      }

Updated: 04/02/98 12:47:30