Product Documentation

c-treeACE V11.0 Update Guide

Previous Topic

Next Topic

User-Defined Function for Conditional Expressions

New "User-Defined Function" (UDF) support for conditional expressions is available. A new function pointer type called ctdbUDFFunc enables this support.

VOID (ctdbDECL* ctdbUDFFunc)( ppVOID args, pVOID retval );

where:

  • args is a list of argument pointer.
  • retval is a return value pointer.

A new c-treeDB API is provided to add a UDF to the given session handle:

CTDBRET ctdbAddUserDefFunc(CTHANDLE Handle, pTEXT funcName, ctdbUDFFunc funcPointer, CTDBTYPE funcRetType, pCTDBTYPE funcArgTypes, COUNT funcArgCount);

where:

  • Handle is a session handle.
  • funcName is the UDF name.
  • funcPointer is the UDF pointer.
  • funcRetType is the UDF return type.
  • funcArgTypes is the UDF argument type list.
  • funcArgCount is the UDF argument list count.

If a function name is not found while parsing an expression, it will be searched on the UDF list by name and it will be executed.

Example:


/* UDF body for a function that inverts a string: "TEST" -> "TSET" */

VOID udftest( ppVOID args, pVOID retval )

{

pTEXT arg1 = (pTEXT)args[0];

pTEXT ret = (pTEXT)retval;

COUNT i, arglen = (COUNT)strlen( arg1 );

for( i = 0; i < arglen; i++ )

ret[i] = arg1[arglen - i - 1];

ret[arglen] = 0;

}

/* Adding UDF for the session handle */

CTDBTYPE arglist[1] = { CT_STRING };

ctdbAddUserDefFunc( hSession, "udftest", udftest, CT_STRING, arglist, 1 );

/* Parser expression using UDF for the record handle */

ctdbParserRecordExpr(hRecord, "udftest( cm_custname )", &exprType, &exprIdx);"

When c-treeDB is active in the library, it is now possible to add a UDF to c-tree’s expression evaluator by defining a UDF list.

Using ISAM/low-level functions to define a UDF list for the current c-tree instance, the list must be initialized with a call to:

udfInit()

Each UDF can be added by calling:

COUNT udfAdd( pTEXT name, ctdbUDFFunc funcPrt, CTDBTYPE retType, pCTDBTYPE argTypeList, COUNT argListCount pinHan )

Before exiting the c-tree environment the list can be released by calling:

udfTerm()

The udfAdd function takes a function pointer having as type ctdbUDFFunc as follows:

VOID (ctdbDECL* ctdbUDFFunc)( ppVOID args, pVOID retval );

where:

  • args is a list of argument pointer.
  • retval is a return value pointer.

When using c-treeDB, it is possible to add a new UDF for the current session by calling:

CTDBRET ctdbAddUserDefFunc(CTHANDLE Handle, pTEXT funcName, ctdbUDFFunc funcPointer, CTDBTYPE funcRetType, pCTDBTYPE funcArgTypes, COUNT funcArgCount);

where:

  • Handle is a session handle.
  • funcName is the UDF name.
  • funcPointer is the UDF pointer.
  • funcRetType is the UDF return type.
  • funcArgTypes is the UDF argument type list.
  • funcArgCount is the UDF argument list count.

If a function name is not found while parsing an expression, it will be searched on the UDF list by name and it will be executed.

Example:


/* UDF body for a function that inverts a string: "TEST" -> "TSET" */

VOID udftest( ppVOID args, pVOID retval )

{

pTEXT arg1 = (pTEXT)args[0];

pTEXT ret = (pTEXT)retval;

COUNT i, arglen = (COUNT)strlen( arg1 );

for( i = 0; i < arglen; i++ )

ret[i] = arg1[arglen - i - 1];

ret[arglen] = 0;

}

/* Adding UDF for the session handle */

CTDBTYPE arglist[1] = { CT_STRING };

ctdbAddUserDefFunc( hSession, "udftest", udftest, CT_STRING, arglist, 1 );

/* Parser expression using UDF for the record handle */

ctdbParseRecordExpr(hRecord, "udftest( cm_custname )", &exprType, &exprIdx);"

Previous Topic

Next Topic

System Group Assignment of Unix/Linux Shared Memory resources

On Unix/Linux systems, a user can belong to more than one group of which one group is the primary group, and all other groups are secondary groups. When the SHMEM_PERMISSIONS option is used to only enable user and group permissions on shared memory resources, the resources created for shared memory connections (files, semaphores, shared memory regions) are assigned with the user's current primary group by default.

To address this situation, a new configuration option, SHMEM_GROUP, has been added preventing a user account that shares a secondary group with the user account under which the FairCom Server process is running failing to connect using shared memory.

This option causes the FairCom Server to assign group membership to the specified group. This option applies to the resources for both the ISAM and the SQL shared memory protocol.

As an example, consider two user accounts:

  • user1 - belongs to groups group1 and group2
  • user2 - belongs to group group2

If the user1 account runs the FairCom Server with SHMEM_PERMISSIONS 660 in ctsrvr.cfg, a client program run by the user2 account will fail to connect using shared memory.

To allow the client program run by user2 to connect, add the following configuration option to ctsrvr.cfg and restart FairCom Server:

SHMEM_GROUP group2

This causes the shared memory resources to be assigned to group group2, which allows the user2 client program to connect.

Previous Topic

Next Topic

Specify Shared Memory Keys on Unix

When more than one FairCom Server was run on a Unix system, the shared memory keys used by different servers could have the same value, which prevented connections to the servers. In addition, it was possible for unrelated applications to collide with default keys generated by c-treeACE servers.

To address this key collision, it is now possible for an administrator to specify specific shared memory keys for ISAM and SQL shared memory communication protocols ensuring the keys do not match existing keys already in use on the system.

New FairCom Server configuration options are available to directly specify a shared memory key. SQL and ISAM each require separate shared memory support


SHMEM_KEY_ISAM <isam_shared_memory_key>

SHMEM_KEY_SQL <sql_shared_memory_key>
 

Shared memory key values can be specified in either decimal or hexadecimal format. For example:


; Set shared memory key for ISAM connections to the specified decimal value:

SHMEM_KEY_ISAM 12345

; Set shared memory key for ISAM connections to the specified hexadecimal value:

SHMEM_KEY_ISAM 0xabcd
 

These server configuration options support specifying an environment variable, whose value is substituted for the configuration option value when the server starts up. For example, if the environment variable MY_ISAM_KEY is set to a numeric value such as 12345 or 0xabcdef before starting the server process, then the following option can be specified in the server configuration file to use this environment variable value for the SHMEM_KEY_ISAM configuration option value:

SHMEM_KEY_ISAM %MY_ISAM_KEY%

Compatibility Notes:

When these configuration options are not used, FairCom Server uses the old method of assigning shared memory keys so its shared memory communication protocol is compatible with old clients. FairCom Server now writes the shared memory key to the shared memory resource file and new clients know to read the shared memory key from this file. If a new client finds no shared memory key in the file, it uses the old method to assign a shared memory key so it is compatible with an old server.

The shared memory resource file is named /tmp/ctreedbs/<server_name> for ISAM, and /tmp/ctreedbs/CTSQL_<sql_port> for SQL, where /tmp/ctreedbs is the default shared memory directory. It can be changed using the SHMEM_DIRECTORY configuration option.

An old client will not be able to connect to a new server using shared memory if the server uses the SHMEM_KEY_ISAM or SHMEM_KEY_SQL configuration option to specify a shared memory key that differs from the shared memory key that the old method would generate.

TOCIndex