Your suggestion is really good.
As soon as possible, I will redirect the spec to the way you show me.
The idea of *alter dde_cluster add member *is really great.. :)
Do you think it's necessary to develop it's grammar in a formal notation,
such as BNF? (or is there any pattern used by MySQL developers?)
Regards,
FM
2005/11/16, SGreen@stripped <SGreen@stripped>:
>
>
>
> Fabricio Mota <fabricio.mota@stripped> wrote on 11/16/2005 01:02:08 PM:
>
> > Hi all again,
> > I'm trying to deicide the best choice for clusters and servers
> management.
> > At the first specification, I suggested to manage it using *insert,
> > update *and
> > *delete *commands over 3 system tables (DDE_CLUSTER, DDE_SERVER and
> > DDE_SERVER_CLUSTER).
> > (old spec is in http://www.geocities.com/fmotaol/DDE/DDEspec.htm)
> > But now, I'm thinking about the possibility to use specific commands for
> > manage it, such as:
> > *create dde_cluster My_dde_cluster (
> > 1 as 'mysql://dbserver.mysql.com:3306/mydb1' user root password 'test',
> > 2 as local user root password 'test',
> > 3 as 'mysql://anotherserver.mysql.com:3306/mydb1' user root password
> 'test'
> > );*
> > * *
> > *subscribe 4 as 'mysql://fourthserver.mysql.com:3306/testdb' into
> > My_dde_cluster user root password 'test';*
> > *unsubscribe 4 from My_dde_cluster;
> > *
> > Despite it might increment a little bit the language parser, it could
> > improve the usability.
> > So, I would like to get this decision not based only in user-side, but
> also
> > in technical aspects, such as development cost and maintainibility.
> > Waiting for suggestions, thank you since now.
> > Regards,
> > Fabricio Mota
> >
> >
> > --
> >
> > Sem mais,
> >
> > Fabricio Mota
> > Oda Mae Brown - Aprecie sem moderação.
> > http://www.odamaebrown.com.br
>
>
> You gain a lot of flexibility by moving from direct INSERT/UPDATE/DELETE
> commands to a parsable grammar. A good example of this is the permissions
> system. By using a single GRANT or REVOKE statement, you could affect
> records in up to three tables at one time. Parsable statements and commands
> isolate the user from changes in the implementation tables. MySQL could
> completely redesign their permissions tables and no application that managed
> user permissions with only GRANT or REVOKE statements would break. If the
> application had been doing it's own INSERTs and such, then the application
> would have to be redesigned in order to work with the new permissions
> schema.
>
> Even if it's a little more difficult to setup, you are much better off in
> the long run creating the statement grammar and writing the parser routines
> to interpret it than you will be if you force your users to manage the
> cluster metadata directly.
>
> That being said, in reference to your CREATE DDE_CLUSTER() example. It
> makes as much sense to me to define an empty cluster and add servers to it
> later as it does to add the servers when you create the cluster. Please
> allow for the option of creating an empty DDE_CLUSTER. I think that if you
> prefix all of your commands with "dde_" then you minimize the risk of doing
> something unintentional.
>
> CREATE DDE_CLUSTER ...
> RECOGNIZE DDE_SERVER ... as serveralias;
> SHOW DDE_CLUSTERS;
> SHOW DDE_SERVERS;
>
> ALTER DDE_CLUSTER clustername ADD MEMBER ...
> ALTER DDE_CLUSTER clustername DROP MEMBER ...
> ALTER DDE_CLUSTER clustername DEMOTE MEMBER ...
> CREATE DDE_PARTITION partitionname ON servername AS ...
>
> As you design your new commands, try to draw parallels from existing SQL
> statements. That will make the learning curve for your new product much
> easier. Don't forget, if you are going to make the DDE engine available on
> v5.0+ that you will need to support the INFORMATION_SCHEMA views as well.
> You can save that for later, though. It's not a priority to getting it
> initially built.
>
> Shawn Green
> Database Administrator
> Unimin Corporation - Spruce Pine
--
Sem mais,
Fabricio Mota
Oda Mae Brown - Aprecie sem moderação.
http://www.odamaebrown.com.br
