Anders,
I didn't see that at first, but now. I'd agree. Maybe I should read
up on stored procedures.
On Mon, July 14, 2014 16:25, Anders Karlsson wrote:
> The order makes quite a big difference, actually. In this case it
> ensures that the ordering of the values in the sort_id column is
> maintai
The order makes quite a big difference, actually. In this case it
ensures that the ordering of the values in the sort_id column is
maintained, even though the numbers are different.
Say this is your data (I have ignored the category thingy for now):
SELECT id, sort_id FROM documents;
+--+---
I would second what m. dykman says. There is no reason I can think of that
you would even be doing the order by clause.
keith
On Sun, Jul 13, 2014 at 11:16 PM, yoku ts. wrote:
> Would you try this?
>
> CREATE PROCEDURE `reset_sortid` (IN category INT(11))
> BEGIN
> SET @a = 0;
>
Would you try this?
CREATE PROCEDURE `reset_sortid` (IN category INT(11))
BEGIN
SET @a = 0;
UPDATE
documents SET sort_id = (@a := @a + 1)
WHERE
document_category = category
ORDER BY
sort_id;
END
//
2014-07-14 11:42 G
why do you need the 'order by' in your update at all? The statement, if
innodb, will certainly be atomic; the order in which they are updated means
nothing.
On Jul 13, 2014 11:46 PM, "kitlenv" wrote:
> maybe try 'order by sort_id desc'?
>
>
> On Mon, Jul 14, 2014 at 12:42 PM, Don Wieland wrote
maybe try 'order by sort_id desc'?
On Mon, Jul 14, 2014 at 12:42 PM, Don Wieland wrote:
> I am trying to create this stored procedure, but can't understand why my
> editor is chocking on it. Little help please:
>
> DELIMITER //
> CREATE PROCEDURE `reset_sortid` (IN category INT(11))
> BEGIN
>
I am trying to create this stored procedure, but can't understand why my editor
is chocking on it. Little help please:
DELIMITER //
CREATE PROCEDURE `reset_sortid` (IN category INT(11))
BEGIN
DECLARE a INT;
SET a = 0;
UPDATE
documents SET sort_id = (a := a
