Note Check the solidDB Release Notes for any limitations that are associated with using a grid in the current release.
When you plan an application for a solidDB grid, you must consider the affect of using a grid at multiple levels of the application architecture. Migrating an existing application (rather than designing a new one) might require too much re-engineering to justify the effort.
The following aspects must be considered when assessing the effort that is involved in migrating an application:
▪ Schema design considerations: A grid has specific requirements for keys and constraints that must be met in order to use partitioned tables, see Schema requirements and recommendations.
▪ SQL statement migration: Although the majority of SQL statements are compatible when you use a grid, INSERT, DELETE and UPDATE statements that affect more than one row typically fail unless the affected rows reside in the same primary partition. These statements must be redesigned such that each statement affects a single row, or to use the grid distributed write mechanism, see Managing distributed non-transactional write operations.
▪ Stored procedure migrations: SQL that is executed inside a stored procedure does not generally work because the solidDB procedure language cannot route the write statements to the appropriate grid node. This part of the application logic must be redesigned and reimplemented by using ODBC or JDBC. solidDB triggers contain procedure language and can be used to validate or change the contents of the row that initiated the trigger. Procedure code that tries to affect other rows does not work unless the other rows reside in same primary partition.
▪ Application level code migration: The application code that executes statements must be updated to process grid-specific error codes, for example, timeouts or grid configuration changes. However, most errors should not require an action as grid functionality is designed to recover automatically.