On 2/5/2013 12:07 PM, Steve Ebersole wrote:
> 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 had assumed that the appropriate database SQL delimiters would be used. By Provider-A and B are you
referring to persistence providers or database 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?
>>
>