Le 2014-02-01 22:48, Chanaka Dharmarathna a écrit :

On Thu, Jan 30, 2014 at 12:57 AM, Marc Delisle <marc@infomarc.info mailto:marc@infomarc.info> wrote:

Chanaka Dharmarathna a écrit :
> Hi,
>
> I'm trying to support the feature request [0]. With that we need
to think
> about export just triggers, just views, just stored
> procedures/functions/events etc. I think this would be practically
needful.
> Anyway, I'm not sure about how we could support this with the current
> custom export form. By adding new radio button (views/triggers/SPs) to
> 'Format-specific options' parallel to structure, data, structure
and data
> options ? Appreciate your thoughts on this.
>
> [0] : http://sourceforge.net/p/phpmyadmin/feature-requests/1403/

Hi Chanaka,
you probably meant checkboxes instead of radio buttons, so that a user
can choose a combination of export sections.

I think that these should be placed under "object creation options" and
"data creation options". Note that you'll need more checkboxes than you
mention, because, to implement this request, a user would want to
disable the normal definition statements likre CREATE TABLE, ALTER
TABLE, etc.

Hi Marc,

I include my suggestions to the custom export form UI [0] using fire bug. I added two elements to the custom export form.

1. The radio button 'only view/trigger/SP' to the 'Format-specific options'
2. The check box 'Add CREATE VIEW statement to the 'Object creation options'

We'll look at how this is going to work.

Item 2 will provide an option to the user, whether to include the view for his export. Basically this will decouple views and tables. This will make as a different feature request.

After item 2 is implemented, user can do export with/without view/sp/trigger. But always export will include at least database structure.

So item 1 will provide an option to not to include database structure to the export. With this option we can hide some options like '|CREATE TABLE| options' in 'Object creation options' section which we don't need.

What do you think on this ?

[0] : http://i.imgur.com/Ri7m4O5.png

Hi Chanaka, In our current form, we have clear choices: structure, data, structure and data (could be improved with just two checkboxes, one for structure and one for data, but this is another subject).

What I find confusing is that you are adding near these choices, another choice which is (I think) a subset of the structure.

I would classify a trigger as being part of the structure (it's more related to structure that to data, right?)

Le 2014-02-02 22:20, Chanaka Dharmarathna a écrit :

>     Chanaka Dharmarathna a écrit :
>     > Hi,
>     >
>     > I'm trying to support the feature request [0]. With that we need
>     to think
>     > about export just triggers, just views, just stored
>     > procedures/functions/events etc. I think this would be
practically
>     needful.
>     > Anyway, I'm not sure about how we could support this with
the current
>     > custom export form. By adding new radio button
(views/triggers/SPs) to
>     > 'Format-specific options' parallel to structure, data, structure
>     and data
>     > options ? Appreciate your thoughts on this.
>     >
>     > [0] : http://sourceforge.net/p/phpmyadmin/feature-requests/1403/
>
>     Hi Chanaka,
>     you probably meant checkboxes instead of radio buttons, so
that a user
>     can choose a combination of export sections.
>
>     I think that these should be placed under "object creation
options" and
>     "data creation options". Note that you'll need more checkboxes
than you
>     mention, because, to implement this request, a user would want to
>     disable the normal definition statements likre CREATE TABLE, ALTER
>     TABLE, etc.
>
>
> Hi Marc,
>
> I include my suggestions to the custom export form UI [0] using fire
> bug. I added two elements to the custom export form.
> 1. The radio button 'only view/trigger/SP' to the 'Format-specific
options'
> 2. The check box 'Add CREATE VIEW statement to the 'Object
creation options'
>
> We'll look at how this is going to work.
>
> Item 2 will provide an option to the user, whether to include the view
> for his export. Basically this will decouple views and tables.
This will
> make as a different feature request.
>
> After item 2 is implemented, user can do export with/without
> view/sp/trigger. But always export will include at least database
structure.
>
> So item 1 will provide an option to not to include database
structure to
> the export. With this option we can hide some options like '|CREATE
> TABLE| options' in 'Object creation options' section which we
don't need.
>
> What do you think on this ?
>
> [0] : http://i.imgur.com/Ri7m4O5.png

Hi Chanaka,
In our current form, we have clear choices: structure, data, structure
and data (could be improved with just two checkboxes, one for structure
and one for data, but this is another subject).

What I find confusing is that you are adding near these choices, another
choice which is (I think) a subset of the structure.

I would classify a trigger as being part of the structure (it's more
related to structure that to data, right?)

Hi Marc,

Yes I agree to your point. In that case, the only problem we have is, there is no way to ignore table structure of the database, if we chose 'structure' or 'structure and data'. For that we should have an option like 'Ignore table structure' under 'Object creation options'. What do you think ?

I believe it would be clearer if we express every option in a positive way. So, a checkbox for all elements on which we can choose, the table structure being one of them. Plus a default value for all these checkboxes, based on the expected need of the majority of users.

Chanaka Dharmarathna a écrit :

On Mon, Feb 3, 2014 at 5:57 PM, Marc Delisle marc@infomarc.info wrote:

...

Le 2014-02-02 22:20, Chanaka Dharmarathna a écrit :

...

>     Chanaka Dharmarathna a écrit :
>     > Hi,
>     >
>     > I'm trying to support the feature request [0]. With that we

need

...

>     to think
>     > about export just triggers, just views, just stored
>     > procedures/functions/events etc. I think this would be
practically
>     needful.
>     > Anyway, I'm not sure about how we could support this with
the current
>     > custom export form. By adding new radio button
(views/triggers/SPs) to
>     > 'Format-specific options' parallel to structure, data,

structure

...

>     and data
>     > options ? Appreciate your thoughts on this.
>     >
>     > [0] :

http://sourceforge.net/p/phpmyadmin/feature-requests/1403/

...

>
>     Hi Chanaka,
>     you probably meant checkboxes instead of radio buttons, so
that a user
>     can choose a combination of export sections.
>
>     I think that these should be placed under "object creation
options" and
>     "data creation options". Note that you'll need more checkboxes
than you
>     mention, because, to implement this request, a user would want

to

...

>     disable the normal definition statements likre CREATE TABLE,

ALTER

...

>     TABLE, etc.
>
>
> Hi Marc,
>
> I include my suggestions to the custom export form UI [0] using

fire

...

> bug. I added two elements to the custom export form.
> 1. The radio button 'only view/trigger/SP' to the 'Format-specific
options'
> 2. The check box 'Add CREATE VIEW statement to the 'Object
creation options'
>
> We'll look at how this is going to work.
>
> Item 2 will provide an option to the user, whether to include the

view

...

> for his export. Basically this will decouple views and tables.
This will
> make as a different feature request.
>
> After item 2 is implemented, user can do export with/without
> view/sp/trigger. But always export will include at least database
structure.
>
> So item 1 will provide an option to not to include database
structure to
> the export. With this option we can hide some options like '|CREATE
> TABLE| options' in 'Object creation options' section which we
don't need.
>
> What do you think on this ?
>
> [0] : http://i.imgur.com/Ri7m4O5.png

Hi Chanaka,
In our current form, we have clear choices: structure, data,

structure

...

and data (could be improved with just two checkboxes, one for

structure

...

and one for data, but this is another subject).

What I find confusing is that you are adding near these choices,

another

...

choice which is (I think) a subset of the structure.

I would classify a trigger as being part of the structure (it's more
related to structure that to data, right?)

Hi Marc,

Yes I agree to your point. In that case, the only problem we have is, there is no way to ignore table structure of the database, if we chose 'structure' or 'structure and data'. For that we should have an option like 'Ignore table structure' under 'Object creation options'. What do you think ?

I believe it would be clearer if we express every option in a positive way. So, a checkbox for all elements on which we can choose, the table structure being one of them. Plus a default value for all these checkboxes, based on the expected need of the majority of users.

Then shall we simply add 'Add CREATE TABLE statement' option to the Object creation options, which is checked by default ? I think this would be the simplest solution with our custom form.

Yes.