dump - load
Bart Pietercil
bart.pietercil at cognosis.be
Sat Jun 14 01:37:26 CDT 2008
Hi Ruslan,
On 14 Jun 2008, at 07:16, Ruslan Zasukhin wrote:
> On 6/14/08 12:06 AM, "Bart Pietercil" <bart.pietercil at cognosis.be>
> wrote:
>
> Hi Bart,
>
>> taking over for a few days from Danny (the man insisted on vacation
>> can you believe it :-))
>
> ----------
>> On the subject:
>> I still believe it should be possible to export tables together with
>> their trigger. I understand your reason (unique in db scope) however
>> for us as developer it is important to be able to transfer a table
>> (and the associated triggers) to another database without needing to
>> dump the whole database (a pain when the db has over 100 tables)
>> since
>> LOGICALLY they are associated.
>
>> So I would plead for a 'with triggers' option when exporting a table
>>
>> as always
>
> Ok, then please fill feature request.
>
> Hmm, no. Look.
>
> Trigger of Table A can also do query on tableB.
> Right?
>
> And what todo ?
Well probably there are even more things that can go wrong, that is
why I would leave it as an option (checkbox) in the export table
command.
I think this is a discussion on protecting a developer against himself
(what you want to do) or empowering a developer (what I want) by
letting him assume responsability.
Importing a table with triggers that refer to a non (or not yet)
existing table is the developers responsability and will lead to an
error when creating the trigger. If the error reporting is good I
don't see a problem with that.
Since we are on the subject there is one more feature I would like to
see in the table export (these options would only be available in
'Structure Only')
Maybe we can have the table export dialog box separated in Normal and
Advanced (this gives a developer already fair warning he needs to know
what he is doing).
In the advanced section you would have the 'include triggers' option
AND (here it comes) the export 'objectpointers as objectpointers'
option.
Same problem: exporting a table structure now converts objectpointers
to longs and leave them as such. I understand the reasoning behind it
(objectpointers may point to non existing tables). However if a
developer knows what he is doing (-->advanced), it is a feature that
would be welcomed.
tia
Bart Pietercil
More information about the Valentina
mailing list