users@jpa-spec.java.net

[jpa-spec users] [jsr338-experts] Re: schema generation open issues

From: Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: Tue, 05 Feb 2013 12:44:11 -0800

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?
>>>>
>>>
>