users@jpa-spec.java.net

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

From: Steve Ebersole <steve.ebersole_at_redhat.com>
Date: Tue, 05 Feb 2013 14:37:39 -0600

Yes, persistence providers. I also don't personally like requiring DB
specific delimiters. Another tenant of JPA is database portability.


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