Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/28—Databases characterised by their database models, e.g. relational or object models
  • G06F16/289—Object oriented databases

Definitions

• TECHNICAL FIELD This invention relates to methods and techniques for integrating relational databases effectively with object oriented applications while ensuring co-existence with an object database.
• Relational databases employed in existing systems represent a significant investment which impedes any more to an object oriented model. It has been difficult to map a relational database to an object oriented model, particularly where it is to co-exist with an object database. This has made it difficult to programmatically access the data of a relational database for an object oriented model.
• relational database can be defined as part of the development of the object oriented application and the application code can make use of embedded SQL commands. Further in a dedicated object oriented application - relational database combination the database can be accessed directly rather than through the Open Database Connectivity (ODBC) layer provided with most relational databases.
• ODBC Open Database Connectivity
• US Patent 5,765,161 discloses a system where data from non-relational, non-object- oriented data stores, such as IBM IMSTM, are encalculated as persistent objects for use in an object oriented application. Such a system does not allow for co-existence with a populated object database.
• US Patent 5,542,078 discloses a system for accessing and integrating non-object oriented data stores with object applications.
• An application using an object database management system is provided with an interface to access foreign data stores which include external data that is mapped and converted into objects for use by the application.
• This system does not allow the mapping of complex relationships between data to manipulate external data with the same degree of effectiveness as data held in the integrated object database.
• SQL structural query language
• the invention in one aspect consists in a method of mapping a relational database schema to an object oriented schema to allow co-existence of said relational database with an object database comprising the steps of:
• mapping columns to attributes (ii) mapping columns to attributes, (iii) defining classes of set, array and dictionary collections based on primary key and index data, (iv) establishing relationships from said primary keys, foreign keys and columns having the same names,
• step (c) generating structural query language (SQL) code fragments to support collection operations from the information derived in step (b) and storing same for run-time access to said relational database, and (d) storing a description of the classes and collections established in step (b) for use in run-time by an object oriented application whenever access to data in said relational database is required.
• SQL structural query language
• the invention consists in a database query engine for an object oriented application which enables access to data in one or more external non-object oriented databases in the same manner as an internal integrated object oriented database to provide data location transparency, said engine comprising: an external class corresponding to each non-object oriented database which determines how a proxy object is populated by instances from the corresponding external database, sub classes which re-implement methods to populate external class instances from said external databases while maintaining an identical interface to internal object classes, a mechanism which produces a representation of the external database schema, and an object identifier to unique key mapping between an external proxy object instance and a row in the external database, said engine carrying out the following processes: assembling SQL statements as determined by the definition of the appropriate external class, appending a JOIN query predicate when accessing a property which is an end point of a bi-directional relationship, binding parameter values obtained from the attribute values of an external proxy instance to parameter markers in said SQL statements, binding parameter values obtained from the operation request which represent dictionary keys binding parameter values obtained from the attribute
• External classes which have two components -namely, an interface and a query specification.
• the interfaces defines the properties (attributes and relationships) and methods if any and their domains; the query specification
• a re-implementation of object manager operations particularly get and set property operations for read or write access to simple attribute values
• An External Collection class using h) provides the protocol to access individual or multiple instances from a subset of a class extent.
• the membership of the collection is constrained by attributes of the collection description as defined in the enriched schema.
• An external Iterator class using h) and/or in collaboration with the External Collection class provides the protocol to iterate 'a collection' of external instances.
• the said external query engine comprises the steps:
• the said external query engine allows:
• the invention therefore provides two complementary areas of functionality: a relational to object schema mapping process, and a query engine that implements in the relational database object oriented access methods.
• mapping is specified declaratively using a "wizard" style mapping tool.
• the external schema wizard (ESW) enables mapping of:
• Tuples (which may be the result of a project/join or a view) to objects.
• SQL types to object language primitive types.
• existing relational database schemas are enhanced to map the relational database into an object model.
• Object concepts and language constructs can then access the data in the external relational database in the same way as data is accessed in the co-existing object database. This then allows a query engine that sits between the object environment and the external databases to implement at runtime the object database access methods.
• GCS Global Conceptual Schema
• a partially automated mapping utility is provided to map relational schema into semantically enriched object model schemas.
• the GCS provides a high-level integrated view of external relational databases as part of an existing object database schema, hiding structural differences between the object model and the relational model. From the application developer's view there appears to be a single unified database.
• the key to the mapping is to discover the relationships between tables in the relational schema and to map these to bidirectional relationships implemented using inverse references.
• mapping will be able to map tuples to objects, SQL types to object primitive types and joins to bi-directional relationships as previously outlined.
• the mapping is declarative, using a 'wizard- style' mapping tool, rather than programmatic. This reduces coding requirements and increases flexibility.
• Data connectivity is provided by the relational database Open Database Connectivity (ODBC) interface, which will be used during the schema transformation phase to access catalogue information and later at 'runtime' to populate virtual object instances via SQL queries.
• ODBC relational database Open Database Connectivity
• ODBC is a widely accepted application-programme interface for database access. It is based on the Call-Level Interface (CLI) specifications from X/Open and ISO/IEC for database APIs and uses Structured Query Logic (SQL) as its database access language. ODBC is designed for maximum interoperability - that is the ability of single application to access different database management systems (DBMSs) with the same source. The query engine will call functions in the ODBC interface which are implemented in database specific modules called drivers.
• CLI Call-Level Interface
• ISO/IEC ISO/IEC
• SQL Structured Query Logic
• Figure 1 shows diagrammatically the architecture of an object oriented system supporting non-object database co-existence
• Figure 2 shows functions performed by the external schema mapping "wizzard" according to the present invention
• Figure 3 shows the architecture of the external query engine of the present invention
• Figure 4 shows a typical run-time configuration of an object oriented system with external database co-existence.
• GCS Global Conceptual Schema
• the proposed GCS architecture is architectured to ensure that it can be readily adapted to support what are commonly referred to as multi-database or federated database systems including non-relational databases such as hierarchical, network or even other OO databases.
• the actual connectivity may employ mechanisms other than ODBC, such as a native call level interface or other high level abstractions such as OLEDB.
• JADE will derive certain useful information directly from the relational catalog, such as primary and foreign key specifications. Often, foreign key relationships will also be deduced based on naming conventions. For example, if "dept-id" is the primary key of the department table then it may be deduced that "dept-id" in the employee table is probably a foreign key. Other information, such as relationship implementation, can be deduced heuristically.
• An 'Object Identifier' to primary key (or special columns) mapping allows the direct mapping of a proxy instance to a row in the relational system.
• the Object identifier property of the proxy denotes the primary key of the relational entity that the proxy is modelling.
• the attribute "dept num" provides a unique handle for each tuple (row) in a Department table.
• the attribute dept_num would play the role of a foreign key in an associated Employee table.
• the OID to primary key mapping is of significance for updating in certain collection operations. For updating a proxy with a searched update it is necessary to uniquely identify the row in the external database which the proxy represents.
• the purpose of the proxy classes is to act as a mediator between the OO world and the relational world. These classes will be derived from a common abstract class: ExternalObject a subclass of the Object class.
• the external proxy classes are instances class type: ExternalClass.
• the proxy classes that comprise the transformation schema have two components: (a) a interface, and (b) a mapping or query specification.
• the interface defines the properties (and methods, if any) and the mapping specification, comprising of 'SLQ- like' queries, defines how to populate a proxy with instances from an external database.
• the tuples or instances retrieved by this query are 'virtual-instances' of the proxy.
• the user must deal with instances of the external classes defined in the schema.
• An external class definition can be mapped from any one of the following relational 'entities': a base table, a view defined in the relational schema, a query e.g. a join, or the result set of a stored procedure
• the properties of an external class may be either: (a) attributes, or (b) external references. Attributes are simple types whose domain is one of the supported JADE primitive types. The type of an external reference can be another external class type or an external collection. External references are used to represent the endpoints of a relationship. External references are always defined as explicit inverses. These references are implemented using mapping methods, which employ either an external object or an external collection method to retrieve an instance or instances.
• ExternalSet An unordered collection may be Class extend optional filtering expression
• the following table lists the ANSI SQL data types and shows the JADE primitive to which they are mapped by default.
• External proxy classes can be organised into an inheritance hierarchy adding further semantics above the relational model.
• an external proxy class could be made a subclass of another provided it met the following requirements:
• the properties mapped in the superclass are a subset of the properties of the subclass
• the 'set of instances' of the subclass are a subset of the 'set of instances' of the superclass
• Summary Mapping technology is used to enhance relational schemas with object model semantics.
• Tables (base, derived or predefined views) are mapped to subclasses of External object.
• Tuples (or rows) map to instances of external classes.
• Each external database is represented by a subclass of ExternalDatabase and a singleton instance.
• Object Identifier to 'primary key' mapping allows unique identification of a tuple and map this to a 'proxy' object.
• Multi-valued properties will be implemented with Dictionary, Set or Array types.
• Schema Transformation Support Overview In order to support the process of transforming a relational schema into an object model a schema transformation "Wizard" is provided within the development environment.
• the Wizard accesses catalog information from selected external data bases and generates classes under the direction of the developer. Some data sources or ODBC drivers may not support all the catalog functions used and some catalogs may not contain all the information required for deriving or suggesting potential relationships.
• the Wizard (1) allows selection of data sources configured on the development machine,
• (13) provides a mechanism to update a mapped object model when the relational schema changes (without having to start from scratch).
• the dept_id foreign key is obtained from the virtual department instance, which is the parent of the virtual employees dictionary.
• the external iterator class will implement the standard iterator protocol i.e. next() and back() methods etc.
• the external iterator/collection collaboration will allow constructs such as for each to function in a transparent fashion.
• External collections implement most of the non-updating collection methods e.g. first, last, size etc.
• External dictionaries provide direct key access to an 'external object instances' i.e. random access to a row or tuple in the relational database.
• Example: department : E Company. departments [name];
• Sequential access External iterators implement the standard iterator protocol and may be used directly. Standard JADE for each syntax is fully supported including reversed and where clause. Class: instances to retrieve 'class extent'.
• An exception class is provided to provide additional information specific to using the ODBC interface. Special consideration is given to detecting and handling changes to the relational schema which may become inconsistent with the schema mapping.
• JADE In the JADE 'for each' instruction, JADE currently optimise special cases when the predicate following the where consists of a conditional key expression. A similar optimisation will be useful when iterating with a for each over an external proxy collection. A special case occurs when the predicate following the where clause contains operands which are all attributes of the collection member type. In this case, the where predicate from the for each can either become the where predicate in the SQL statement or can be conjoined with an existing where predicate in the query specification associated with the external collection.
• An External Database class will provide transaction support and direct SQL execution with beginExternalTransaction, commitExternalTransaction, abortExternalTransaction.
• a class can be defined from one or more base tables. If multiple tables are specified it is equivalent to a JOIN. If a class is defined as a JOIN of two or more tables its unique or primary key columns will be the combination of all the tables unique or primary key columns. By selecting only those attributes which are required for a class a table projection can be effected, ie the class can access a subset only of the columns for the table. This has resource and performance benefits for large tables and joins.
• Each external class defined must include attributes (possibly hidden) that correspond to the unique or primary key columns of the tables it uses. This is required to give each object uniqueness. This is necessary for random updating and the collection method 'includes'.
• Attribute Mapping methods are created for all attributes that have a base type of
• Reference Mapping methods are created for all for single references. This method calls getProxy with feature number of the reference property to allow the returning of the appropriate proxy.
• Rules for collection candidate creation Create a dictionary for each index of the class if all the columns of the index have corresponding user defined attributes ie not hidden. Create a dictionary based on the primary key of the class if all the columns of the primary key have corresponding user defined attributes ie not hidden. Create an array based on the primary key of the class if all the columns of the primary key have corresponding user defined attributes ie not hidden. Create a set for each class.
• Relational to Object Oriented Heuristics Cardinality Use the cardinality of the respective tables to indicate the cardinality of the relationship between the corresponding classes.
• cardinality information is not available then a relationship is based on a primary key/foreign key pair is likely to be a one to many relationship. If no delete rule information is available assume a peer-peer relationships.
• Orderltems OrderltemArray
• OrderSet Set of Order
• OrderltemArray Array of Orderltem ordered by .lineOrder
• Intermediate tables are tables that are used to allow an M:M relationship to be implemented between two other tables. They can have additional columns beyond those participating in the relationship or they can consist solely of those columns.
• the ExternalReference.joinPredicate and the ExternalReference.joinPredicatelnfo properties are used for reference querying using the late-binding technique.
• the keyEqPredicatelnfo consists of an integer for each '?' in the keyEqPredicate. Each integer is the ordinal of the key to be bound as a parameter at runtime. This method must handle both single and multiple key collections.
• Collection geqKey,gtKey,leqKey,ltKey Determines the key ⁇ CmpOp>Predicate and key ⁇ CmpOp>PredicateInfo required for a key ⁇ CmpOp> operation on an ExternalDictionary, where ⁇ CmpOp> can be Geq, Gtr, Leq, Lss.
• the key ⁇ CmpOp>Predicate consists of a comparison term for each key of the collection.
• Each factor consists of a column identifier, a comparison operator and a '?' placeholder for bound parameters.
• the key ⁇ CmpOp>PredicateInfo consists of an integer for each '?' in the key ⁇ CmpOp>Predicate. Each integer is the ordinal of the key to be bound as a parameter at runtime. This method must handle both single and multiple key collections.
• geqKey Given a dictionary with keyl, key2 etc corresponding to column 1, column2 the terms for geqKey are :
• the includesPredicate consists of an equality term for each unique column of the tables that are used by the collections member class. Each term consists of the columns identifier, an '- sign and a '?' placeholder for bound parameters. All these terms are ANDed together and enclosed in braces.
• the includesPredicatelnfo consists of an integer for each '?' in the includesPredicate. Each integer is the column/attribute ordinal of the parameter to be bound at runtime. This method must handle both single and multiple table classes, and both single and multiple unique column tables.
• column2 Given a collection with a member class whose table(s) have unique columns column 1, column2 the terms for includes are :
• This fragment is optionally specified by the user.
• Table identifies are generated from the table name, and any schema and catalog names specified for the table. These are combined according to the driver information for their usage, prefix/suffix usage and the driver quote character. Instead of using table identifiers directly, correlation names (also known as aliases ) are used, unless the driver does not support this. Table name aliases are defined in the FROM clause and are used instead of table identifiers in SELECT, and WHERE clauses. Table name aliases are generated that are unique across the entire External Database definition and not just for a particular query.
• Column identifiers are a combination of a column's table identifier ( or alias ) and its name separated by a '.' character.
• the relational Query engine has two functions as indicated in figures 1 and 3. The first is to implement the behaviour of external proxy classes and collections that provide access to external databases (see also figure 4). The second is to provide catalog Query functions, which import catalog information from an external database populating meta information objects used by the External Schema ESW.
• the query engine will provide methods on the external schema entities used by the external schema Wizard to import catalog information from a relational schema. These methods will employ the relevant ODBC catalog functions. Some drivers/data sources may not support all the required functions, in which case the external schema Wizard have less information to use for producing a default mapping.
• the JADE query engine will always query driver capability to determine whether a required function is available before using it.
• the schema transformation process creates an object model, which can be employed by developers as an abstract O-O view of a relational database.
• the query engine will implement the required access methods to allow this abstract object model to work.
• the query engine will also depend on a number of stored SQL queries and mapping methods generated by the external database wizard.
• ExternalDatabase Each external database is mapped to a subclass of the a class called ExternalDatabase, which has a singleton persistent instance.
• the external database class provides properties and methods relevant to the external data source and connection.
• a transient instance is created; this instance can be accessed in user logic to invoke database specific operations.
• ExternalClass implements behaviour specific to external proxy classes.
• the class is used by the query engine when creating virtual proxy instances.
• each external class will contain the SQL query required to populate a 'class extent' or to do a join query for a single valued reference.
• ExternalCollClass implements behaviour specific to external collection classes. The class is used by the query engine to populate an external virtual collection.
• the user will access the relational database using the OO language and by navigating relationships via inverse references, e.g. in JADE it will be possible to code the following style of iterative access: foreach emp in dept.employees do emp.displayO; endfo reach;
• the dept_id foreign key will be obtained from the virtual department instance, which is the parent of the virtual employees dictionary.
• the external iterator class will implement the standard iterator protocol i.e. next() andback() methods etc.
• the external iterator/collection collaboration will allow constructs such as foreach to function in a transparent fashion.
• External collections will implement non-updating collection methods e.g. first, last, size etc.
• External dictionaries will provide direct key access to an 'external object instances' i.e. random access to a row or tuple in the relational database.
• Relative key access will be provided using getAtKeyGtr, Geq, Leq and Lss style methods.
• the external database wizard will generate stored SQL queries for the standard key search operations implemented at the external dictionary level. These will be in the form of parameterised SQL statements. DHOC QUERY EXTENSIONS
• the filterExpression allows the SQL WHERE clause associated with a collection to be specified or overridden and the sortExpression allows the SQL 'ORDER BY' clause to be specified or overridden.
• External iterators implement a standard iterator protocol and may be used for iterating over any external collection.
• Standard JADE foreach syntax is fully supported including reversed and where clause.
• the ExternalClass instances property is implemented to provide access to the class extent in a similar fashion to the existing JADE Class: instances 'virtual collection' property. If the extemal class has a defined ORDER BY, then instances will be retrieved in this order, otherwise the order will be data-source dependent.
• a filter ('WHERE' clause) may be defined in the External database wizard to restrict the rows included class extent.
• ExtemalDatabase class will provide transaction support using beginExternalTransaction, commitExternalTransaction and abortExternalTransaction methods.
• NonCursor or searched updates will be possible using the ExternalDatabases::executeSQL method.
• Positioned or cursor-based updates will be supported by an external collection method to create a new instance (insert a row) and external object methods to delete or apply updates to an external object.
• ExternalObject :deleteSelf ExternalObj ect: :update
• Attributes of a proxy can be updated in the same fashion as normal JADE objects, by using the assignment operator.
• ODBC drivers are use (see figure 4) This is because the use of the ODBC standard does not itself enure interoperability.
• the ODBC standard is very broad and one of its goals is to allow a large number of DBMSs to expose as wide a feature set as possible.
• Drivers are provided to work with a single DBMS and, by definition, are not interoperable. They play a role in interoperability by correctly implementing and exposing ODBC over a single DBMS.
• the query engine will aim to be capability driven as opposed to employing driver or data source specific code as far as possible.
• the query engine will interrogate connected ODBC drivers and make use of certain features when available. Examples include catalog functions, block mode and scrollable cursors. In other cases the way we use the driver has to be tailored based on the requirements of the driver and the way the data source behaves.
• the getExternalDatabase method returns a reference to the shared transient instance of the extemal database identified by dbName.
• the ExtemalDatabase class represents a connection to an external database and provides methods that operate on the data source.
• connectionString Contains parameters required to connect to a data source serverName
• the name of the server as defined for the data source userName Contains a user-id to be used to establish a connection password Contains password is required by the data source
• This string should contain any parameters required for connecting to a data source.
• the parameters are generally driver/data source specific.
• a default connection string can be obtained automatically when connecting to a data- source using the Extemal database wizard browse facility. However, the default string can be overridden at runtime on a per user or connection basis by setting this attribute.
• the UID and PWD parameters should not be included in this string.
• This attribute contains the name of the database server if this is defined for the data source.
• ExtemalDatabase :userName userName : String
• This attribute should contain the name of a valid user id, used for authentication at the data source.
• a default user-id is established at design time using the Extemal database wizard. However, this of course may be changed at run-time on a per user basis, prior to opening a database connection.
• ExtemalDatabase : password password : String
• the password attribute is used in conjunction with userName for authentication, if required, at the data source.
• a default password may be stored on the database object, if the schema translator has allowed this. In any case, this may be changed at run-time on a per user basis, prior to opening a database connection.
• connectionString, userName and password(if this is required by the data source) must be set before opening a connection. Default values for these are established by the Extemal database wizard.
• ExtemalDatabase rclose close()
• This method closes any open connection to the extemal database.
• ExtemalDatabase :canTransact canTransact() : Boolean
• ExtemalDatabase :isUpdateable isUpdateable() : Boolean
• ExternalDatabase :beginExternalTransaction beginExternalTransaction();
• this method should be called at the end of a series of updating operations: creates, deletes and updates to commit or apply the changes to the extemal database. If the extemal database doesn't support transactions(use the canTransact method to determine this), then calling this method will have no effect.
• ExternalDatabase :abortExternalTransaction abortExternalTransaction() ;
• this method can be used to undo the effects of a transaction. All updating operations: creates, deletes and updates made since the last beginExternalTransaction call are reversed to the state that existed at the time of that call. If the extemal database doesn't support transactions(use the canTransact method to determine this), then calling this method will have no effect.
• ExtemalDatabase :executeSQL executeSQL(sql : String);
• ExtemalDatabase :checkSQL isSQLValid(sql : String) : Boolean; Call this method to check that the syntax of an SQL statement is both valid and supported by the driver and data source. The method returns true if the syntax is valid and supported, otherwise it returns false. No exception is raised if the syntax is not acceptable.
• extemal collection classes represent the 'result set' of a selection from an extemal data source.
• the extemal collections are virtual in the sense that member instances don't actually exist until they are first referenced.
• an extemal proxy instance is created which represents the corresponding row in the result set.
• Extemal collections provide the operations to support direct and relative key access and may be used in collaboration with extemal iterators to access rows in a result set sequentially.
• ExtemalCollection class inherits the interface of the Collection class and most non-updating methods will be implemented and supported. Extemal collections are in themselves read-only. Operations such as add, remove, clear and purge are not supported. The compiler will prevent the use of updating methods for extemal collections in the same way that they are prevented for automatic collections participating in an inverse relationship.
• filterExpression Used as a filter to select specific rows sortExpression Used to control how instances are ordered in the collection ExternalCollection::filterExpression filterExpression : String;
• This attribute may be specified to override the default filtering or WHERE predicate defined for an extemal collection. This may be useful for selecting a subset of records at runtime.
• the filtering expression should not contain the WHERE keyword.
• the filtering expression must be defined in terms of extemal column names, not the attribute names to which they are mapped. If the resultant SQL statement is not valid then an ODBC exception will be raised.
• This attribute may be specified to override the default sort or SQL 'ODER
• the sort expression should not contain the 'ORDER BY' SQL keywords.
• the filtering expression must be defined in terms of extemal column names, not the attribute names to which they are mapped. If the resultant SQL statement is not valid then an ODBC exception will be raised.
• createlterator Creates an extemal iterator for an extemal collection first Returns the first entry in the collection getOwner Returns the parent or owner of the collection includes Returns true if the extemal collection contains a specified object inspect Provides an inspector for extemal instances last Returns the last entry in the collection canCreate Returns true if member type instances may be created createObject Create a new extemal proxy instance size Retums the current number of entries in the collection
• the createlterator method is used to create an extemal iterator for use with extemal collections.
• the first method retums a proxy reference representing the first entry in the virtual collection.
• a proxy reference representing the first entry in the virtual collection.
• ordered collections such as dictionaries and arrays the proxy will represent the first row selected as determined by the 'ORDER BY' clause.
• the getOwner method retums the owner or parent of the extemal collection
• ExtemalCollection includes(value: MemberType): Boolean;
• The includes method retums true if the virtual collection or result set contains the specified object. This method will result in a key equal query based on the attributes which comprise the primary keys of the proxy.
• the last method retums a proxy reference representing the last entry in the virtual collection. For ordered collections such as dictionaries and arrays the proxy will represent the last row selected as determined by the 'ORDER BY' clause.
• the SQL query used to retrieve the last record will be constructed to give the optimiser the opportunity to perform a singleton select. In cases where an index exists on attributes in the ORDER BY a sort should also be avoided.
• the size method retums the number of entries in the virtual collection. This method will result in an SQL query that will actually count the rows in the selected tables mapped to the proxy class. This method should therefore be used with caution if there are expected to large number of rows in the result- set.
• This method determines whether instances of the member-type of the collection can be created. This method will retum false if either the data- source is read-only or the class of the collection members is read-only. An external class will be read-only if it is based on a relational view or join query defined by the Extemal database wizard.
• An extemal array is an ordered virtual collection which represents the rows in a result set generated from an SQL query containing a sort specification i.e. an 'ORDER BY' clause. The member instances occur in the order determined by the 'ORDER BY' Subscripting External Arrays
• bracket [ j subscript operators may be used to access rows at a specified position in the result-set, for example to access the nth transaction in an extemal array called transactions, you may do the following:
• ExternalArray :at at(index: Integer): MemberType;
• the at method retums the entry in the virtual array at the position specified by the index parameter. This corresponds to accessing the nth row in the result- set.
• An extemal set is an unordered virtual collection which represents the rows in a result set generated from an SQL query which has no sort specification (ORDER BY). The order in which instances are fetched is data-source dependent.
• Class ExternalSet public, transient
• ExternalSet includes(key: MemberType): Boolean;
• The includes method retums true if the virtual collection or result set contains the specified object. This method will result in a key equal query based on the attributes which comprise the primary keys of the proxy.
• An extemal dictionary is an ordered virtual collection which represents the rows in a result set generated from an SQL query with a sort specification (ORDER BY).
• ORDER BY The 'ORDER BY' specification is generated by the External database wizard and represents the order specifications defined for the member-key attribute values.
• bracket [ ] subscript notation can be used as a shortcut for the getAtKey method which supports random access with a key equal search condition. For example:
• getAtKey Retums the object at the specified key getAtKeyGeq Retums the object with a key greater or equal to the specified key getAtKeyGtr Retums the object with a key greater than the specified key getAtKeyLeq Retums an object with a key less than or equal to the specified key getAtKeyLss Retums an object with key less than the specified key includesKey Retums true if the receiver contains an entry at the specified key startKeyGeq Sets a start position within a collection for an iterator object startKeyGtr Sets a start position within a collection for an iterator object at the next object after the specified key startKeyLeq Sets a start position within a collection for an iterator object at the object equal to or before the specified key startKeyLss Sets a start position within a collection for an iterator object at the object before the specified key
• the getAtKey method issues a singleton SQL select which searches for an exact match between the member-key attribute values of virtual instances (rows) and the corresponding key parameters. If a row is selected, then a proxy reference representing the row is retumed; otherwise, the method retums null.
• the getAtKeyGeq method issues a singleton SQL select that searches for a 'greater than or equal' key match between the member-key attribute values of virtual instances (rows) and the corresponding key parameters. If a row is selected, then a proxy reference representing the row is retumed; otherwise, the method retums null.
• the getAtKeyGtr method issues a singleton SQL select that searches for a greater than key match between the member-key attribute values of virtual instances (rows) and the corresponding key parameters. If a row is selected then a proxy reference representing the row is retumed; otherwise, the method returns null.
• the getAtKeyLeq method issues a singleton SQL select that searches for a ess than or equal' key match between the member-key attribute values of virtual instances (rows) and the corresponding key parameters. If a row is selected then a proxy reference representing the row is retumed; otherwise, the method retums null.
• ExternalDictionary::getAtKeyLss getAtKeyLss(keys: KeyType): MemberType;
• the getAtKeyLss method issues a singleton SQL select that searches for a 'less than' key match between the member-key attribute values of virtual instances (rows) and the corresponding key parameters. If a row is selected then a proxy reference representing the row is retumed; otherwise, the method retums null.
• the includesKey method issues a singleton SQL select which searches for an exact match between the member-key attribute values of virtual instances (rows) and the corresponding key parameters.
• the method retum tme if a row is selected, otherwise, it retums false.
• the startKeyGeq method sets a start position within a collection for an iterator object.
• the startKeyGtr method sets a start position within a collection for an iterator at the next object after the key specified in the Keys parameter
• ExternalDictionary :startKeyLeq startKeyLeq(keys: KeyType; iter: Externallterator);
• the startKeyLeq method sets a start position within a collection for an iterator object at the object equal to or before the key specified in the keys parameter.
• the startKeyLss method sets a start position within a collection for an iterator object at the object before the key specified in the keys parameter.
• the Externallterator class is used in collaboration with an extemal collection.
• An extemal iterator instance is used to access the virtual instances of the collection sequentially, either forwards or in a reverse direction.
• extemal iterators will provide the operations to scroll an SQL cursor associated with the result set of the query, which was used to populate the extemal collection.
• Externallterator :back back( value: ExtemalObject output) : Boolean updating
• the back method is used to scroll backwards through an SQL result-set and retum a proxy-reference representing each row as the cursor is scrolled.
• the getCollection method retums the extemal collection currently associated with the receiver. A null value is retumed if no collection is associated with the receiver.
• the back method is used to scroll forwards through an SQL result-set and return a proxy-reference representing each row as the cursor is scrolled.
• the reset method resets the state of an iterator. After an iterator has been reset, the first next or back operation will cause the default SQL query associated with the attached extemal collection to be re-issued.
• Externallterator rstartAtlndex startAtIndex(index: Integer) updating;
• the startAtlndex method is used to position a cursor at a specified row in the result-set.
• the required position is specified in the index parameter.
• This attribute will contain a native error code, specific to the data source. A description of the meaning of this should be available in the documentation for the data source.
• This attribute will contain the five-character ODBC state code retumed by the ODBC driver. The first two characters indicate the class of the error; the next three indicate the subclass.

Priority Applications (3)

Applications Claiming Priority (2)

Publications (1)

Family

ID=19926402

Family Applications (1)

Country Status (3)

Cited By (14)

Families Citing this family (1)

Citations (5)

• 1998
  • 1998-08-14 AU AU90101/98A patent/AU9010198A/en not_active Abandoned
  • 1998-08-14 WO PCT/NZ1998/000128 patent/WO1999009494A1/en not_active Application Discontinuation
  • 1998-08-14 EP EP98941947A patent/EP1019851A1/en not_active Withdrawn

Patent Citations (5)

Also Published As

Similar Documents

Legal Events