Object Translator

The Object translator, known by the name of map-cache, is a bridge for reading and writing java objects from external sources (i.e., Map cache) and delivering them to the engine for processing.  And to assist in providing that bridge, the OBJECTTABLE function is an alternaitive means for transforming complex java objects into rows and columns.

Search Capabilities

Supports a local cache that is of type Map and it uses key searching on the map to find objects.

Supported Capabilities

The following are the connector capabilities when Key Searching is used:

  • SELECT command

  • CompareCriteria - only EQ

  • InCriteria

  • Insert, Update and Delete

Usage

  • Retrieve objects from a cache and transform into rows and columns.

  • Perform inserts, updates and deletes to the cache

Properties

Object translator is capable of returning to the client application the java object stored in the cache. To enable the translator to automatically include the object as a column in the metadata, use the following Import Properties.

Import Properties

Property Name Description Required Default

ClassObjectColumn

If true, and when the translator provides the metadata, a column of object data type will be created that represents the stored object in the cache

false

false

Metadata

Requirements for Defining Table for Root Class

Table level requirements

  • The table for the root class, must have a primary key defined, which must map to an attribute in the class.

  • The table name (or the name in source) must match the name of the Pojo class name. This is how the table is matched to the registered class in the cache.

Note
 The primary key data type for the attribute in the class must match the cache key data type.

Column level requirements

  • The class object column that represents the cached object should have a name in source of 'this'.  All other columns will have their name in source (which defaults to the column name) interpreted as the path to the column value from the primary object.

  • All columns that are not the primary key nor covered by a lucene index should be marked as SEARCHABLE 'Unsearchable'.

  • Attributes defined as repeatable (i.e., collections, arrays, or map) or a container class, can be supported as 1-to-* relationship, and will have corresponding registered class (if they are to be searched).

Requirements for Defining Child Table in a Relationship

A relationship needs to be defined if the primary class contains a complex object type that you want to query.

Supported relationships

  • 1-to-1 - must have getter/setter for a single object

  • 1-to-many - must have getter/setter for a Collection, Map or Array type.

Table level requirements

  • The table name (or the name in source) must match the name of the Pojo class storing the child information. This is how the table is matched to the registered class(s) in the cache.

  • The child table must have a foreign key that maps to the parent table primary key.

  • The name in source for the foreign key is the name of the parent class method to access the child objects.

Example for Defining Metadata

The following is an example of a Person that can have Phones. This demonstrates how to define the primary class and a relationship using DDL.

public class Person {

   public String name;
   public int id;
   public String email;

   public List<PhoneNumber> phones;

   public String getName() {
      return name;
   }

   public void setName(String name) {
      this.name = name;
   }

   public int getId() {
      return id;
   }

   public void setId(int id) {
      this.id = id;
   }

   public String getEmail() {
      return email;
   }

   public void setEmail(String email) {
      this.email = email;
   }

   public List<PhoneNumber> getPhones() {
      return phones;
   }

   public void setPhones(List<PhoneNumber> phones) {
      this.phones = phones;
   }

}

public class PhoneNumber {

   private String number;
   private String type;

   public String getNumber() {
      return number;
   }

   public void setNumber(String number) {
      this.number = number;
   }

   public String getType() {
      return type;
   }

   public void setType(String type) {
      this.type = type;
   }
}

Note, this also shows a container class, PhoneNumber, as an example of the foreign key that’s defines the relationship.

<vdb name="PersonVDB" version="1">
    <model name="PersonModel" visible="false">
        <source name="objsource" translator-name="map-cache" connection-jndi-name="java:cache-jndi"/>
        <metadata type="DDL"><![CDATA[

                CREATE FOREIGN TABLE Person (
	                PersonObject object OPTIONS (NAMEINSOURCE 'this', SELECTABLE FALSE, UPDATABLE FALSE, SEARCHABLE 'Unsearchable', NATIVE_TYPE 'org.jboss.as.quickstarts.datagrid.hotrod.query.domain.Person'),
	                id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SEARCHABLE 'Searchable', NATIVE_TYPE 'int'),
	                name string OPTIONS (NAMEINSOURCE 'name', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'),
	                email string OPTIONS (NAMEINSOURCE 'email', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'),
	                CONSTRAINT PK_ID PRIMARY KEY(id)
                ) OPTIONS (UPDATABLE TRUE);

                CREATE FOREIGN TABLE PhoneNumber (
	                id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE FALSE, UPDATABLE FALSE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'),
	                number string OPTIONS (NAMEINSOURCE 'phone.number', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'),
	                type string OPTIONS (NAMEINSOURCE 'phone.type', SEARCHABLE 'Unsearchable', NATIVE_TYPE 'java.lang.Enum'),
	                CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'phones')
                ) OPTIONS (UPDATABLE TRUE);

         ]]> </metadata>
    </model>

</vdb>

This metadata could also be defined by using the Teiid Designer.

JCA Resource Adapter

results matching ""

    No results matching ""