On 5/21/2012 4:32 PM, Steve Ebersole wrote:
>
>
> On 05/18/2012 01:51 PM, Linda DeMichiel wrote:
>>
>>
>> On 5/18/2012 8:26 AM, Steve Ebersole wrote:
>>>
>>> On Thu 17 May 2012 07:14:19 PM CDT, Linda DeMichiel wrote:
>>>>> Another related thing to consider is "auxiliary database objects";
>>>>> basically allowing create/drop definitions for
>>>>> database objects other than those explicitly named in mappings.
>>>>> Functions, procedures, view, etc, etc.
>>>>>
>>>>
>>>> Right. This would be doable via the scripts
>>>
>>> You mean the "init scripts"? If so, I'd caution against that plan. For
>>> these auxiliary objects you need both create and
>>> drop capability, whereas typically the init script will only contain
>>> "create" information (INSERTS, etc).
>>>
>>
>> No, I had assumed that these would be in the DDL scripts.
>
> Perfect. But, are you planning on allowing both user-provided DDL and persistence provider generated DDL scripts to be
> used simultaneously? If not, users would have no way to define "auxiliary database objects" using persistence provider
> generated DDL scripts. Unless, of course, there is an annotation for them to define "auxiliary database objects"
>
> Is the plan:
> 1) only allow "auxiliary database objects" with custom DDL scripts
> 2) allow mixing custom DDL script and persistence provider generated DDL scripts
> 3) provide annotations (or other means) to tell persistence provider about "auxiliary database objects" to be generated
> into the DDL script
What I had been assuming was that there would be one set of scripts, which might have been produced
iteratively -- e.g., running the persistence provider to generate DDL scripts, then customizing /
augmenting them with additional auxiliary database objects and/or perhaps further tuning them.
I hadn't been contemplating (3).