Well I just mean that commands in a script file might be delimited in a
number of ways (eol-delimited, semicolon-delimited, keyword-delimited,
etc).
It is usually not feasible to handle the entire contents of such a "data
loading script" as one big string, especially for sending to the
database directly via JDBC. Typically you want to be able to handle
command-by-command. Hence the command delimiter.
As an exmaple, if Provider-A assumes end-of-line as the command
delimiters and Provider-B assumes semicolon users will not be able to
feed the same script to both providers.
I just think it makes sense to be up front about expectations in this
regard in the spec. Are providers expected to parse the import script
in the same fashion? Are we saying this is just totally provider
defined (and therefore completely non-portable)?
This is where I was saying that Hibernate actually uses an interface to
allow for multiple delimiter schemes to be used and plugged in;
basically it takes a Reader and breaks it down into String[] of the
commands. That is obviously extremely flexible.
On 02/05/2013 01:22 PM, Linda DeMichiel wrote:
>
>
> On 2/5/2013 9:13 AM, Steve Ebersole wrote:
> [snip]
>
>> 4) WRT "data loading", the question of delimiter is still open. I
>> think this ought to be spelled out in the spec,
>> otherwise provider portability will be a major problem.
>>
>
> [I want to separate this item out, since the rest of the changes seem
> stable.]
>
> I'm not sure I understand what you mean by this? Are you referring to
> a property to
> cover the SQL terminator character in scripts?
>