Fixing a mistake

Name
Email
Subject
Comment *
File	Select/drop/paste files here
* = required field	[▶ Show post options & limits] Confused? See the FAQ.

Embed	(replaces files and can be used instead)
Options	Do not bump (you can also write sage in the email field) Spoiler images (this replaces the thumbnails of your images with question marks)
Password	(For file and post deletion.)
Allowed file types:jpg, jpeg, gif, png, webm, mp4, swf, pdf Max filesize is 12 MB. Max image dimensions are 10000 x 10000. You may upload 5 per post.

File: 73b228188d9cbe3⋯.jpg (19.37 KB, 480x360, 4:3, mistake.jpg)

Fixing a mistake Anonymous 11/18/16 (Fri) 00:34:39 4fe43f No.4509

When I started using Hydrus a while back, I decided to have leading spaces on all the tags in namespaces.

Don't ask.

Now I've decided it's time to stop being an ass and standardize back to namespace:tag instead of namespace: tag. I don't know much Mysql, but after some brief reading the solution seemed obvious enough: Head over to client.master.db (after backup) and run "UPDATE tags SET tag = LTRIM(tag)." Except:

"Error while executing query: column tag is not unique"

Oops.

Turns out I'm not just a moron, but a sloppy moron. In 94 cases the whitespaced tag already exists as a regular tag, so I can't cut off the whitespace or the resulting tag won't be unique. Hey, no problem I thought, I'll just re-map those 94 regular tags to spaced tags in Hydrus and then delete them in the db since they're not mapped to anything. Unfortunately Hydrus (understandably) can't handle tags going missing from the db, even if they're no longer in use, and there's no clean way to delete them that I can see.

So I'm at a loss. I have roughly 1600 whitespaced tags to fix. Any thoughts on the best way to attack this?

Anonymous 11/18/16 (Fri) 20:46:15 4fe43f No.4514

Alright, fixed it.

If anyone's curious, I added "old" on to the 94 dupe tags manually, thus making them unique and allowing the LTRIM to work. Then I cleaned out/adjusted the sibling and parent listings in hydrus, wherever an "old" tag popped up. Then I just made sure to replace any "old" tags still on images; luckily this number was low since they mostly represented mistakes rather than an intentional naming convention.

hydrus_dev ## Board Owner 11/19/16 (Sat) 20:53:54 e320a2 No.4517

File: 6d4c83dcf8a29a9⋯.jpg (37.55 KB, 640x480, 4:3, 6d4c83dcf8a29a95bd522a7ac6….jpg)

>>4514

Well done for figuring this out so quick. Let me know if you get any new problems. My feeling is that you got it right and won't have any, though.

This sort of thing has come up a couple times before, including trying to mass-rename underscore_separated tags. I've had some ideas for another tag cache layer that make more in-program sibling tools easier to construct, but it would double the size of the db, so I've put it off. For now, maybe I could add an option to 'hard collapse' a sibling, to actually substitute all the entries at the db level and keep all the complicated internal logic consistent. There's still no easy way to add lots of siblings in one go, but it would make autocomplete counts and so on more accurate.

hydrus_dev ## Board Owner 11/19/16 (Sat) 20:55:13 e320a2 No.4518

Oh, now I think of it, I can easily add an option to render all tags as 'namespace: tag' if you prefer the leading space.

Anonymous 11/19/16 (Sat) 23:33:15 b44604 No.4521

>>4517

>For now, maybe I could add an option to 'hard collapse' a sibling, to actually substitute all the entries at the db level and keep all the complicated internal logic consistent.

Not the OP of this thread, but please do! I have a shitload of siblings that are simply tags for which I had already added parents and children before realizing they had typos or other errors, and I'd like to collapse all of them.

Anonymous 11/20/16 (Sun) 19:59:51 34489f No.4527

>>4521

>>4517

Could this also solve my issue here >>4250?

Anonymous 12/05/16 (Mon) 01:56:38 516f4f No.4672

File: d176273fc7d2e67⋯.jpg (1.13 MB, 1851x1300, 1851:1300, SS_Austria_shipwreck.jpg)

>>4518

OP here. Appreciate the response.

The spacing was just a dumb choice on my part; I thought it would be annoying to read without it, but after some usage I've found the standard way works fine for me.

That said, the ability to work with a tag issue involving most or all of the db in a more effective way would probably be good to have eventually, though it's not high priority. Building your own booru is a learning process, and I'm sure I'm not the only one who's made some dumb naming convention mistakes.