10 SODA Guidelines and Restrictions
General guidelines and restrictions that apply across SODA implementations are presented.
- SODA Guidelines
Guidelines that apply across SODA implementations are described. - SODA Restrictions (Reference)
Restrictions that apply across SODA implementations are described.
10.1 SODA Guidelines
Guidelines that apply across SODA implementations are described.
-
AL32UTF8 database character set — Oracle recommendsFoot 1 that you use AL32UTF8 (Unicode) for your database character set. Otherwise:
-
Data can be altered by SODA when documents are written to a collection, because of lossy conversion to the database character set. (This affects only collections stored as
VARCHAR2
andCLOB
data; collections stored asBLOB
data do not depend on the database character set. -
Query-by-example (QBE) can return unpredictable results.
-
-
Re-creating a collectionFoot 2 — Do not drop a collection and then re-create it with different metadata if there is any application running that uses the collection in any way. Shut down any such applications before re-creating the collection, so that all live SODA objects are released.
There is no problem just dropping a collection. Any read or write operation on a dropped collection raises an error. And there is no problem dropping a collection and then re-creating it with the same metadata. But if you re-create a collection with different metadata, and if there are any live applications using SODA objects, then there is a risk that a stale collection is accessed, and no error is raised in this case.
Note:
In SODA implementations that allow collection metadata caching, such as SODA for Java, this risk is increased if such caching is enabled. In that case, a cache can return an entry for a stale collection object even if the collection has been dropped.
See Also:
-
Key Column Type for information about the importance of using AL32UTF8 with client-assigned document keys
-
Oracle Database SODA for Java Developer's Guide for information about collection metadata caching
Parent topic: SODA Guidelines and Restrictions
10.2 SODA Restrictions (Reference)
Restrictions that apply across SODA implementations are described.
-
Document size:
-
For SODA for REST and SODA for Java the limit is approximately 2 gigabytes.
-
For SODA for PL/SQL the size is limited by the maximum possible LOB size.
See Also:
Oracle Database SQL Language Reference for information about the maximum size for
BLOB
andCLOB
Note:
You must ensure that you have sufficient RAM to support your workload.
-
-
JSON document content:
In SODA, JSON content must conform to the JSON RFC 8259 standard, if database initialization parameter
compatible
is at least20
, or to the RFC 4627 standard, ifcompatible
is less than20
. RFC 8259 support includes RFC 4627 support (and RFC 7159 support).In Oracle Database release 19c and prior, only RFC 4627 was supported. RFC 4627 allows only a JSON object or an array, not a scalar, at the top level of a JSON document. For example, according to RFC 8259, the string value
"hello"
is, by itself, valid JSON content; but according to RFC 4627, it is not.In addition, SODA JSON content can be UTF-8 or UTF-16 (big endian (BE) or little endian (LE)). Although RFC 4627 also allows UTF-32 (BE and LE) encodings, SODA does not support them. Some implementations may support additional, non-Unicode, encodings.
See Also:
-
IETF RFC 8259 for the JSON RFC 8259 standard
-
IETF RFC 4627 for the JSON RFC 4627 standard
-
Parent topic: SODA Guidelines and Restrictions
Footnote Legend
Footnote 1: SODA for C requires that you use AL32UTF8 as the database character set.Footnote 2:
Day-to-day use of a typical application that makes use of SODA does not require that you drop and re-create collections. But if you need to do that for any reason then this guideline applies.