The write task writes a list of records into a specified Record Store instance.
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.gzextension if it is a compressed file. Required.-h (or --host) specifies the host where the CAS Service is running. If the flag is omitted, the default is the value of the
com.endeca.itl.cas.server.hostproperty incommandline.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.portproperty as an SSL port. A value of false uses HTTP and treatscom.endeca.itl.cas.server.portas 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 CAS Service. If the flag is omitted, the default is the value of the
com.endeca.itl.cas.server.portproperty incommandline.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-transactiontask to commit the write operation. If this flag is omitted, the operation is done in auto-commit mode. Optional.
Example 25. 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.
