Because experience tells us (Hibernate team) that users do not like
writing scripts that are line delimited. Also, our interface allows
handling of comments, etc that might need to be ignored.
I guess as long as the language we use does not exclude persistence
providers from using more user-friendly options in parsing the import
script, its fine.
On Tue 05 Feb 2013 02:44:11 PM CST, Linda DeMichiel wrote:
>
>
> On 2/5/2013 12:37 PM, Steve Ebersole wrote:
>> Yes, persistence providers. I also don't personally like requiring DB
>> specific delimiters. Another tenant of JPA is
>> database portability.
>>
>
> However, if this isn't database delimiters, then why aren't newline
> characters enough?
>
>
>>
>> On 02/05/2013 02:10 PM, Linda DeMichiel wrote:
>>>
>>>
>>> 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?
>>>>>
>>>>
>>