:wtf: How can this be so wrong??? (AKA the Discopocalypse thread)
-
Oh. How typical...
-
I wonder if the "edit all the text" feature that we don't currently have covers changing it.
I'd assume not but it's Discourse so *shrug*
-
Oh. How typical...
Tried searching on 'name' - discovered this, of which I was previously unaware...
But there doesn't appear to be any finer granularity between Everywhere and Nowhere.
-
-
No 'root' or 'discourseadmin'
-
Oh, but you forgot the REASON why "user" is on that list. I'm pretty sure it's upstream somewhere. But you see, "user" appears in some URLs in discourse. And those are special magical URLs. And poor Discourse gets confused when user appears in an URL in some cases, and either crashes or exposes private data.
So, you see, rather than fixing that, we need to ban "user"....
-
@Lorne_Kates said:
So, you see, rather than fixing that, we need to ban "user"....
Still better than just saying:
"No user will ever call him/herself 'user'! So no need to do anything. Also if anybody ever uses that name, I will tell them they are doing it wrong and close any topic they appear in".
Filed Under: Granted, not MUCH better .... but it's the small steps that count
-
LOL @moderator
-
Lol @TL1, @TL2, @TL3, @TL4, @belgium
-
@Lorne_Kates said:
So, you see, rather than fixing that, we need to ban "user"....
BUT we need to "ban" those special usernames in a way that the admins can actually un"ban" them. So the admin can break stuff and then we can blame them for breaking it rather than the software for letting them break it.
That's DiscoSupport 101.
-
@Lorne_Kates said:
No it is not possible, we do not store the (git version + date it started running) in a table
I literally don't know what the fuck any of that means. How do you store history data, but not in a table, and you can't access it so what's the point of a history of data
I guess they changed structure of this
enumin their code. But didn't migrate all the old values they have stored in the database.So at some point, their customers updated Discourse, which then started writing in "wrong" (or I guess different) enum values into the DB. So now they have half the DB with the old schema and half with the new one. Without some kind of a record of when each instance was updated, there's no way they can go through database and pick which numbers are "wrong" and need to be remapped.
Their solution is to add the log of discourse updates.
Fine, that's a nice thing to have. But the real solution IMO is NOT to use
enum-s at all, but string constants. That way the database would retain full meaning of their data, instead of relying on ruby code to interpret it.
-
Even if I had a blog it wouldn't be under my real name.
Some kind of boring technical blog under your real name is not necessarily a bad thing to have a link to on your résumé (or some kind of blog/résumé hybrid blogsumé-type thing...], but in general, the sort of thing that goes on here will probably not help you find a job...
-
But the real solution IMO is NOT to use
enum-s at all, but string constants. That way the database would retain full meaning of their data, instead of relying on ruby code to interpret it.
Yay string constants in the database! What could possibly go wrong?
Oh wait, there are those mysterious things called normalization and internationalization. And performance.The real solution is to hard-code the enum values and never ever fucking change them. If Ruby can't do that, one more reason to use a less stupid language.
And if you really do need the enum meaning in the database, add a mapping table and join that.
-
@Discopope said:
Engineering is hard, let's go
shoppingDiscoursering!
-
The real solution is to hard-code the enum values and never ever fucking change them. If Ruby can't do that, one more reason to use a less stupid language.
If only it were possible to generate an integer value from a string, some kind of function perhaps? Could end up making a hash of it if you weren't careful though, admittedly...
-
But the real solution IMO is NOT to use enum-s at all, but string constants. That way the database would retain full meaning of their data, instead of relying on ruby code to interpret it.
Believe me, this is a frustrating approach when trying to internationalise your product. Especially when you end up having to map from English to German/Russian/Chinese for display, and then back again for storing in the DB. Far better to use static enums that never change as then you just have to use a different set of resources rather than have translation routines getting in the way...
For once,
is almost doing it right. Almost.
-
+Ű
-
But the real solution IMO is NOT to use enum-s at all, but string constants. That way the database would retain full meaning of their data, instead of relying on ruby code to interpret it.
Yay string constants in the database! What could possibly go wrong?
Oh wait, there are those mysterious things called normalization and internationalization. And performance.The real solution is to hard-code the enum values and never ever fucking change them. If Ruby can't do that, one more reason to use a less stupid language.And if you really do need the enum meaning in the database, add a mapping table and join that.
Unless you have serious performance issues, I'd still go with strings. Data safety beats performance in most projects.
Normalization and i18n concerns are pure nonsense in this case.
Ruby has the same enum implementation as most other languges. Which is to say poor.
-
Believe me, this is a frustrating approach when trying to internationalise your product. Especially when you end up having to map from English to German/Russian/Chinese for display, and then back again for storing in the DB. Far better to use static enums that never change as then you just have to use a different set of resources rather than have translation routines getting in the way...
Err... What?
These string constants are a dream for i18n. Just map them to the translation file and you're good to go. Much better than numbers.
-
Assuming everybody has done it correctly at every stage. Which they haven't. Ever. The code base will almost certainly have large numbers of hard coded references to string constants, which you will have to find and fix. It will require going through every line of code, making sure that there are no hardcoded strings in there.
Having been there and done that, I am telling you now, I would prefer a standard of using numerical values mapping to enums any day. It prevents the idiot on the team fucking up, and is immediately obvious when they have.
-
Having been there and done that, I am telling you now, I would prefer a standard of using numerical values mapping to enums any day. It prevents the idiot on the team fucking up, and is immediately obvious when they have.
Like it was obvious to the discodevs? Two weeks later?
Look i'm not saying hardcode strings. Just reference global string constants instead of global enums using whatever construct your language allows (static class, hash...).
It's db friendly, it's API friendly, it's i18n friendly, it's better for multi-app project. The only downside is a SLIGHT performance penalty. But it's a win on the average in my experience.
-
Just reference global string constants instead of global enums
I agree that it looks nicer, and as long as you can trust your team to do this consistently then it isn't a bad idea. My problem being that I don't trust other developers enough to assume they will correctly use global string constants if they are creating a new module. In fact I trust them to hard code variables given the 1/2 chance that offers. Yes, this can be solved with module frameworks to build on, but it makes life a lot simpler to use enums in the database and use their lazyness to direct them down the proper route...
-
I still don't get how hard it is to just give the enums an explicit number.
Public Enum DiscourseFuckupTypes DoingItWrong 1, WorksOnMyMachine 2, ThatIsDifferent 3, MoreCPURequired 4 OK502 7 End EnumOh look you can insert a new Enum anyfuckingwhere in that structure, and it still works. And then you'll know what the database ID needs to be.
VB can do it. Why can't DjangoLore?
-
Far better to use static enums that never change as then you just have to use a different set of resources rather than have translation routines getting in the way...
Bullshit. Just use a uuid like god intended. Using enums is just daring someone to change it.
-
You mean GUID.
UUID is so 1985.
-
@Lorne_Kates said:
I still don't get how hard it is to just give the enums an explicit number.
Easy, but then you've got to keep the mapping somewhere and make sure that all the clients of the database use the same mapping. There's a bunch of ways to fix this, but the best of all is to keep the mapping in a table in the database itself and make the enum field be actually a foreign key.
-
the best of all is to keep the mapping in a table in the database itself and make the enum field be actually a foreign key.
Quite.But the real solution IMO is NOT to use enum-s at all, but string constants. That way the database would retain full meaning of their data,
No. A million times no. The enums that the discotwunts have embedded in their code are keys. Keys should almost never have any implied or embedded semantic meaning.They've managed to avoid that particular issue, probably via cargo cult development if all is known, it's just that in doing so they've efectively managed to move part of their database into their codebase. Because they are stupid fuckholes who, in a world where
is the norm, they manage to even wrong
-
Is it just me or is it a bug that the title of this topic has an emoji in it that doesn't render anywhere?
-
Nah, titles are different
-
Discoursistently so.
-
If only it were possible to generate an integer value from a string, some kind of function perhaps? Could end up making a hash of it if you weren't careful though, admittedly...
And then you get collisions, and trying to handle those, and you're really in trouble. BTDTGTTS. Though that one was on user data.
We did over time move from IDs to technical names for DB columns. So instead of '1' we'd store 'like', which is then translated to 'Like' in the frontend.
-
Look i'm not saying hardcode strings.
Okay. Because that's what I thought you meant.Just reference global string constants instead of global enums using whatever construct your language allows (static class, hash...).
Meh. I still prefer surrogate keys.
-
No. A million times no. The enums that the discotwunts have embedded in their code are keys. Keys should almost never have any implied or embedded semantic meaning.
They've managed to avoid that particular issue, probably via cargo cult development if all is known, it's just that in doing so they've efectively managed to move part of their database into their codebase. Because they are stupid fuckholes who, in a world where
is the norm, they manage to even :doingit_wrong: wrong_Keys can be strings too.
I guess what I'm saying is if you need an immutable unique word-like data type, the most natural primary key for this datatype is this string itself, not some unrelated integer.
-
Keys can be strings too.
… if you are unaware of the problems of using strings as keys. If you have somehow found a use case where you require a string as a key, you should almost always use its hash, and not the string itself.String compares are slow. Joins on string indexes are slow. Capitalisation is significant. Embedded spaces are significant. The string you thought was unique and immutable usually turns out to be neither one nor the other. You open yourself to unicodɘ abuse. Programmers will embed strings all over their code. They will directly use little Bobby Tables to query the database.
About the only time you should be using string keys is when you're doing full text search.
I guess what I'm saying is if you need an immutable unique word-like data type, the most natural primary key for this datatype is this string itself, not some unrelated integer.
And what I'm saying is that you're wrong. You use some surrogate value that is under your control as the key, and add a unique constraint on the string.
-
String compares are slow. Joins on string indexes are slow
Yup. I included performance penalty in the downsides.
Capitalisation is significant. Embedded spaces are significant. The string you thought was unique and immutable usually turns out to be neither one nor the other. You open yourself to unicodɘ abuse.
None of these are an issue for the suggested enum-like usage.
And what I'm saying is that you're wrong. You use some surrogate value that is under your control as the key, and add a unique constraint on the string.
And what I'm saying is that you're wrong. And since I have a better avatar than you, that makes me right.
-
Is it just me or is it a bug that the title of this topic has an emoji in it that doesn't render anywhere?
Discowhitespace failure.
-
From the multi-container thread
:The discussion got heated cause it is hard not to be defensive when people tell you, you are doing it wrongThe cycle is complete. The student has surpassed the master.
-
None of these are an issue for the suggested enum-like usage.
Really?Let's take a concrete example. ISO country codes. I mean, it's one of the most likely uses of a string key that makes sense, right?
- It's fixed length, which means you can use
CHARinstead ofVARCHAR, thus avoiding most of the performance penalties - It's an enumeration.
- No embedded spaces
However...
- Capitalisation is important.
GB≠gb≠Gb≠gB - Although entries are guaranteed unique at any point in time, they are not immutable, nor are they guaranteed not to be reused. See, for example,
DEorCZ GB≠㎇
All entirely possible for causing problems, and that's for something which is backed up by an international standards body. Apart from the last one, these are issues I have seen in live code.
since I have a better avatar than you, that makes me right.
Can't argue with that.
- It's fixed length, which means you can use
-
Really?
Let's take a concrete example. ISO country codes. I mean, it's one of the most likely uses of a string key that makes sense, right?
It's fixed length, which means you can use CHAR instead of VARCHAR, thus avoiding most of the performance penalties
It's an enumeration.
No embedded spacesHowever...
Capitalisation is important. GB ≠ gb ≠ Gb ≠ gB
Although entries are guaranteed unique at any point in time, they are not immutable, nor are they guaranteed not to be reused. See, for example, DE or CZGB ≠ ㎇
All entirely possible for causing problems, and that's for something which is backed up by an international standards body. Apart from the last one, these are issues I have seen in live code.
Look at the avatar, @tufty
LOOK AT IT!
Seriously, for anything where capitalization is important, I wouldn't use the string-based-enum system.
-
Look at the avatar, @tufty
Ummmm - yeah? Yours is derivative of a tired TV show, and mine is inspired. I'd use a smiley here, but fuck that shit.
@cartman82 said:Seriously, for anything where capitalization is important, I wouldn't use the string-based-enum system.
The problem is that, by using your non-capitalisation-sensitive data as a key, you've managed to make it sensitive to capitalisation, and so, everywhere you use it, you'll be doingLCASEorUCASE, or facing the consequences. It will come back to bite you.
-
It will come back to bite you.
Not if you've got validation against a fixed set. Which you would have if you're modelling an enum, yes? If you're not doing that, it's not an enum, it's a folksonomy…
-
[quote=sam]
I am strongly in the "whatever works and solves the problem" camp.
[/quote]No, you're in the Discourse camp.
-
I think you spelled Jonestown wrong...
-
Just use a uuid like god intended. Using enums is just daring someone to change it.
md5sum(GUID)is better...Ah, no, that might clash with other parts of the software...
-
The problem is that, by using your non-capitalisation-sensitive data as a key, you've managed to make it sensitive to capitalisation, and so, everywhere you use it, you'll be doing LCASE or UCASE, or facing the consequences. It will come back to bite you.
Wasn't this the usecase where you control the software platform accessing the data? If you've got users manually updating that stuff, those arguments may make sense. If you do not, just standardize on one casing. And don't use LCASE or UCASE cause there go your indexes.
-
And don't use LCASE or UCASE cause there go your indexes.
Some RDBMSs let you create indexes on stuff like
lower(<column_name>);)
-
Is it just me or is it a bug that the title of this topic has an emoji in it that doesn't render anywhere?
Looks ok to me (it even twinkles)... Firefox for the win?
The category on the other hand...
-
-
Why isn't :twinkie: an emoji yet?
Now you've made me crave cake. Maybe I can get my wife to make one this week …
And no, a food-like substance that has a better chance of surviving the apocalypse than a cockroach does not count.
-
It does now, it didn't before someone added a space.
Also the title change is to demonstrate Discourse supporting some features in some places but being unclear what it supports where.
Folksonomy - Wikipedia
