The syntax for this task is:
recordstore-cmd write -a RecordStoreInstanceName [-b]
-f InputFile [-h HostName] [-l true|false] [-p PortNumber] [-r Type] [-x Id]
where:
- -a (or --instanceName) specifies the name of a Record Store instance. Required.
- -b (or --baseline) is a flag with no arguments that specifies that this is to be a baseline write. If the Record Store has any existing generations, a baseline write will not delete those previous generations, however, it will mark them as "to be deleted" and the cleaner will delete them when it runs (if the records are older than the generation retention time). If the flag is omitted, the write operation is considered an incremental write to the last-committed generation. Optional.
- -f (or --file) specifies the file that contains Endeca records. The filename extension will determine the format of the input file. Valid extensions for the file are .xml (for an XML format) and .bin (for a binary format); either file type can also have an additional, optional .gz extension if it is a compressed file. Required.
- -h (or --host) specifies the host where the Endeca CAS Service is running. If the flag is omitted, the default is the value of the com.endeca.itl.cas.server.host property in commandline.properties. If the property is not set, the value then defaults to localhost. Optional.
- -l (or --isPortSsl) specifies whether to communicate with the service using an HTTPS connection. A value of true uses HTTPS and treats the com.endeca.itl.cas.server.port property as an SSL port. A value of false uses HTTP and treats com.endeca.itl.cas.server.port as a non-SSL port. Specify false if you enabled redirects from a non-SSL port to an SSL port. Optional.
- -p (or --port) specifies the port of the Endeca CAS Service. If the flag is omitted, the default is the value of the com.endeca.itl.cas.server.port property in commandline.properties. If the property is not set, the value then defaults to 8500. Optional.
- -x (or --transaction) specifies the active transaction ID to use. If you use this option, you must follow the command with a commit-transaction task to commit the write operation. If this flag is omitted, the operation is done in auto-commit mode. Optional.
Examples of writing records
If there are two generations in the Record Store, this command:
recordstore-cmd write -a RS2 -b -f basedata.xml
will write the records in the
basedata.xml file as a baseline write operation. If you check the log output, you should see messages similar to these:
Starting new transaction with generation Id 3
Started transaction 10 of type READ_WRITE
Processing delete all for generation 3
Marking generation committed: 3
Committed transaction 10
The Delete message (
Processing delete all for generation 3) indicates that the transaction that created Generation 3 also marked the previous generations for deletion.
If you then perform a subsequent incremental write command:
recordstore-cmd write -f incrdata.xml
the console or log output messages should look like these:
Starting new transaction with generation Id 4
Started transaction 11 of type READ_WRITE
Marking generation committed: 4
Committed transaction 11
At this point, the Record Store has two generations: Generation 3 is a baseline generation and Generation 4 is an incremental generation. If you then run a Forge baseline update, it will use both generations.