Sheeri K. Cabral wrote:
On Wed, Oct 7, 2009 at 5:50 PM, Ronald Bradford
<[email protected]> wrote:
I would have to agree with what's been said.
You do want to be more strict.
You do want to record resulting actions, not commands.
But that *is* a record of the action -- "if the table exists, drop
it." That means that on the master, that table doesn't exist,
regardless of whether or not it existed before.
(consider REPLACE, INSERT IGNORE and INSERT....ON DUPLICATE KEY UPDATE
which are similar in that they're IF a, DO b, ELSE DO c and thus
aren't "strict" statements of what changes).
I totally understand what you're saying above, Sheeri, but I disagree.
The *action* was not taken. A decision was made, sure, but no action
was taken which *changed the state of the server*.
The transaction log used by replication contains only messages that
represent atomic units of change on a server, not the statements which
were executed on the server -- if you want that, we have regular logging
plugins. :)
For things like REPLACE or INSERT ... ON DUPLICATE KEY UPDATE, the
transaction log will contain messages which represent the exact changes
done to the underlying tuples.
For instance, if a REPLACE statement affected a single existing row in a
table, the transaction log will contain a single Transaction message,
containing 2 Statement messages. The first Statement message will be of
type DELETE and will contain the original tuple information. The second
Statement message will be of type INSERT and contain the new tuple
information.
For an INSERT ... ON DUPLICATE KEY UPDATE, if the statement affected an
existing row in a table, a single Transaction message containing a
single Statement message of type UPDATE will be sent to the transaction log.
I'm fine with whatever happens with "IF EXISTS" and also the analog
"CREATE...IF NOT EXISTS" but I think it's important to recognize that
they can count as a "record of action".
:) We'll have to agree to disagree. I think IF (NOT) EXISTS should
really be removed. If not removed, it should not be used as a crutch or
hack for replicated environments. As it stands now, IF (NOT) EXISTS
does only one thing: change a potential error into a warning for the
client. That said, I don't believe warnings belong in an RDBMS. Errors
are errors :)
I'll be blogging more about the newly-revised replication system shortly
(once phase 2 hits the trees). In the meantime, I've put quite a bit of
documentation into the new transactional message proto file, which you
can see here:
http://bazaar.launchpad.net/~jaypipes/drizzle/replication-group-commit/annotate/head%3A/drizzled/message/transaction.proto
Cheers!
Jay
p.s. Note that the statement above about a Transaction message
representing an atomic change in the state of a server is not quite
accurate in the case of bulk operations. The difference for bulk
operations is explained in the transaction proto file linked above.
-Sheeri
You should be tied down to the mysql way.
On Oct 7, 2009 5:42 PM, "Brian Moon" <[email protected]> wrote:
On 10/7/09 3:42 PM, Sheeri K. Cabral wrote: > > oh, definitely! One of the
reasons I use "IF EXISTS...
I think this sums it up for me. While I lean on things like this in
MySQL now, I would kind of like things to be a bit more strict.
On 10/7/09 3:45 PM, Monty Taylor wrote: > > I do not believe it should. The
replication log in Dri...
Yeah, I think it should be a list of changes as well. Seems "correct".
Brian. _______________________________________________ Mailing list:
https://launchpad.net/~drizz...
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
