|
not extensible enough, rename to TWENTY_TWO_BLANK_SPACES
|
#
?
Dec 12, 2017 22:26
|
|
|
|
| # ? Jun 5, 2024 13:28 |
|
|
Elman posted:
I remember some stupid legitimate reason for having to do that like 20 years ago. drat if I remember what it was, but just that I spent like most of a day trying to figure out another way to handle it. It was C++ and we were slicing a std::string for <reasons> and having a static one to do it turned out to have a big perf boost. However this was also the project that before I came along spent something like 60% of it's CPU time in std::string constructor. Which was addressed by changing about 2000 method signatures from foo(std::string bar) to foo(const std::string& bar)...
|
|
#
?
Dec 12, 2017 22:33
|
|
|
Volguus posted:There's always need for speed, and there's never a need for arbitrarily reducing it. The system will have enough bottlenecks as it is, why introduce a new one for no reason? UUIDs are fine if you have distributed databases, but if you don't, why bother? "Because then you can just slap a record in the database without worrying about ID collision or having to ask it what ID it came up with. Perfect for anything a user creates on the fly." - the Indian contractors who did V1 of our core system
|
|
#
?
Dec 12, 2017 23:01
|
|
|
Munkeymon posted:the cheap contractors who did V1 of our core system Fixed that for you. It's not the nationality that's the problem.
|
|
#
?
Dec 12, 2017 23:08
|
|
|
Munkeymon posted:"Because then you can just slap a record in the database without worrying about ID collision or having to ask it what ID it came up with. Perfect for anything a user creates on the fly." - the Indian contractors who did V1 of our core system Funny that you mention that. About 10 years ago I was working at a relatively big company (which since has faded into obscurity and was making smartphones that were named after a fruit) and was assigned to a project to help them actually deliver something after almost 1 year of delays (the project was several years old, but the delay was only 1 year). Out of 20 people assigned to that project, 18 were TATA consultants. My first look at the database, there were no primary keys (no column was assigned the "primary key" attribute in any of the tables) and no foreign keys (of course). When I asked why? "We solve conflicts in software"  Anyway, after pestering them for weeks they finally grudgingly agreed to add primary keys to the tables (no foreign keys, but hey ... baby steps). What do they add? UUIDs. Better than nothing, but ... haha.
|
|
#
?
Dec 13, 2017 00:20
|
|
|
repiv posted:Twitters API legitimately has to encode Tweet IDs as strings because they exceeded 2^53 Tweets, so the IDs can no longer be represented as Javascript numbers TooMuchAbstraction posted:To be honest, if you asked me to pick an ID format for something, I'd probably pick 64-bit int by default. That's 18 sextillion! That's a lot! The fact that this is limited to 9 quadrillion in Javascript would not have immediately leapt out to me as a problem. Twitter didn't run out, they wanted to make it easier to generate tweet IDs by splitting it into timestamp/machine/sequence. Which is fair, but they decided they needed to lay it out as 4 billion tweets per second for 70 years, taking 63 bits. They could have easily fit it in 53 bits if they wanted to. A pure tweet counter would be around 40 bits right now. Dylan16807 fucked around with this message at 00:42 on Dec 13, 2017 |
|
#
?
Dec 13, 2017 00:40
|
|
|
Munkeymon posted:"Because then you can just slap a record in the database without worrying about ID collision or having to ask it what ID it came up with. Perfect for anything a user creates on the fly." One random 64-bit integer stored as an 8 byte integer, &c, 48MB. Probability of next insertion collision 2^44. Use two 64-bits if you have the need for higher collision avoidance, and still shave off half the storage requirements. Sadly I've seen these where the number of rows is around 100M.
|
|
#
?
Dec 13, 2017 01:28
|
|
|
PhantomOfTheCopier posted:Yes let us see... A 128-bit UUID stored as a 36 byte string, as a primary key, hence indexed, and as a foreign key, let us suppose in two other tables and indexed. 1M rows per table. 36*2*3*1M=216MB. Probability of next insertion collision 2^108. That's why you drop the 2ish bits from the UUID that specify the type and are fixed for the type you're using and put them in your signed 128 bit number type then you have the exact same storage requirements as your 2 64 bits.
|
|
#
?
Dec 13, 2017 01:42
|
|
|
PhantomOfTheCopier posted:A 128-bit UUID stored as a 36 byte string Nobody actually does this, right?
|
|
#
?
Dec 13, 2017 02:05
|
|
|
My DB primary keys are composite keys of every column.
|
|
#
?
Dec 13, 2017 02:11
|
|
|
My primary key is the json column.
|
|
#
?
Dec 13, 2017 02:29
|
|
|
Sedro posted:Nobody actually does this, right? If you dont have the UUID type in the database, how else are you gonna store it? 2 64 bit ints? nah....
|
|
#
?
Dec 13, 2017 03:13
|
|
|
Volguus posted:If you dont have the UUID type in the database, how else are you gonna store it? 2 64 bit ints? nah.... Time for a REALLYBIGINT type.
|
|
#
?
Dec 13, 2017 03:21
|
|
|
Sedro posted:Nobody actually does this, right? Hi is this your first day in the thread
|
|
#
?
Dec 13, 2017 03:39
|
|
|
Kazinsal posted:Time for a REALLYBIGINT type. See previous post DECIMAL(128, 0) postgresql types can take a UUID if you drop the type bit.
|
|
#
?
Dec 13, 2017 03:49
|
|
|
PostgreSQL has a built in uuid type. https://www.postgresql.org/docs/9.1/static/datatype-uuid.html I've seen engineers cling to their uuid designs stored as MySQL strings for primary keys everywhere as if it would keep the Titanic afloat. They usually seem to recognize some absurdity, so they truncate it to save space.  Edit: Yeah it's a common MySQL antipattern. vvvv Haha. Also, PostgreSQL has a native inet type. Just cast it to an ipv6 address.  Edit 2: There's a 16 byte interval type. I don't know if it would work, but it could be converted to microseconds since, as we all know, they have the same storage requirements so they're the same.  Edit 3: Interval fails as microseconds (out of range), but the inet type behaves: select trim(trailing ':' from regexp_replace(replace('01234567-89ab-cdef-fedc-ba9876543210'::uuid::text,'-',''),'(....)',E'\\1:','g'))::inet; PhantomOfTheCopier fucked around with this message at 05:10 on Dec 13, 2017 |
|
#
?
Dec 13, 2017 04:25
|
|
|
Sedro posted:Nobody actually does this, right? I've seen them stored as a 38 byte string (with braces around it just to make sure you realize it's a GUID). Naturally it was a VARCHAR(100) column.
|
|
#
?
Dec 13, 2017 04:27
|
|
|
 Do you enjoy byte order issues? Isn't it nice how you cannot just make a GUID into bytes by taking away the dashes but you also have to flip the byte order of several fields because Microsoft once treated it as a combination of integers and backward compatibility being what it is, it remains so in many systems? That being said, if you use sequential IDs in your datebase, I hate you and think you belong in this thread.
|
|
#
?
Dec 13, 2017 06:34
|
|
|
Let me tell you about our integration layer that tries to keep track of sequential ids for inserts independently of the database.
|
|
#
?
Dec 13, 2017 06:41
|
|
|
Nhibernate HiLo? We hit an INT limit on our user table once, decided to change it to UUID but that broke replication and we ended up detaching a few thousand relations before realising and having to try and fix that poo poo by hand.
|
|
#
?
Dec 13, 2017 09:45
|
|
|
Sedro posted:Nobody actually does this, right? Microsoft requires you to transmit a GUID as a 78-byte null terminated UTF-16 string with braces over USB for some WinUSB functionality.
|
|
#
?
Dec 13, 2017 11:10
|
|
|
EssOEss posted:That being said, if you use sequential IDs in your datebase, I hate you and think you belong in this thread. I thought sequential integer IDs indexed better? TooMuchAbstraction posted:Fixed that for you. It's not the nationality that's the problem. Of course not, it's the toss-requirements-over-the-wall offshoring... which usually does (did?) seem to happen with Indian firms, and definitely did in this case.
|
|
#
?
Dec 13, 2017 15:41
|
|
|
Volguus posted:There's always need for speed, and there's never a need for arbitrarily reducing it. The system will have enough bottlenecks as it is, why introduce a new one for no reason? UUIDs are fine if you have distributed databases, but if you don't, why bother? That's... an almost perfect example of missing the point about the bottleneck analogy. If your system has 'enough bottlenecks as it is', then as long as you're working downstream of a bigger one, that's precisely when you shouldn't optimize for speed, because the system won't benefit from it unless the bigger bottleneck is removed. Using UUID is far from arbitrarily reducing speed, either (can't think of any example of that, other than sprinkling sleep() around). They make idempotency trivial, for example, and they make any kind of data sharing between databases safe and easy.
|
|
#
?
Dec 13, 2017 16:03
|
|
|
b0lt posted:Microsoft requires you to transmit a GUID as a 78-byte null terminated UTF-16 string with braces over USB for some WinUSB functionality. 
|
|
#
?
Dec 13, 2017 16:15
|
|
|
NihilCredo posted:That's... an almost perfect example of missing the point about the bottleneck analogy. If your system has 'enough bottlenecks as it is', then as long as you're working downstream of a bigger one, that's precisely when you shouldn't optimize for speed, because the system won't benefit from it unless the bigger bottleneck is removed. If in your database you store your UUID as varchar (for whatever reason, incompetency or the database support), you are arbitrarily reducing speed. Made some tests many years ago on an Oracle database, testing varchar vs bigint as primary keys, and the insert was slightly slower while the select was a lot slower (more than 15% is I remember correctly). However, yes, if you need to share data between databases, this is a hit that you are accepting and is part of the core functionality. There's no way around it. Using the UUID type in the database would most likely improve things to the point that speed is equal, though I have not personally tested that.
|
|
#
?
Dec 13, 2017 16:30
|
|
|
Munkeymon posted:I thought sequential integer IDs indexed better? Yes, in theory, but the convention is to replace the last 4 bytes of GUIDs with a timestamp, which at least in SQL Server basically makes them sequential without losing enough randomness to matter. There is also a builtin function in T-SQL for doing something along the lines of this. Mind you, I have never noticed a difference when benchmarking this with any of the databases I have worked with (not more than low tens of GBs of data, so perhaps too small to matter really). Perhaps it only shows up under heavier load than I ever run into. Volguus posted:If in your database you store your UUID as varchar (for whatever reason, incompetency or the database support), you are arbitrarily reducing speed. Right, just as you would if you wrote files to disk by uploading them to an FTP server and then using wget to save them to My Documents. That's just not an appropriate way to do this. There is a difference between paying a price in functionality by "optimizing" something without a need (as when using ints, thereby giving up GUID features) and just doing it wrong (in which case you win nothing, such as when storing GUIDs in their string-serialized form as varchar). EssOEss fucked around with this message at 17:04 on Dec 13, 2017 |
|
#
?
Dec 13, 2017 17:01
|
|
|
EssOEss posted:Yes, in theory, but the convention is to replace the last 4 bytes of GUIDs with a timestamp, which at least in SQL Server basically makes them sequential without losing enough randomness to matter. There is also a builtin function in T-SQL for doing something along the lines of this. You mean https://www.codeproject.com/Articles/388157/GUIDs-as-fast-primary-keys-under-multiple-database ?
|
|
#
?
Dec 13, 2017 19:02
|
|
|
Yeah, that article appears to accurately represent the concept, though it manages to be impressively verbose about it.
|
|
#
?
Dec 13, 2017 22:51
|
|
|
code:
Elman fucked around with this message at 10:25 on Dec 14, 2017 |
|
#
?
Dec 14, 2017 10:21
|
|
|
You know what? I'm fine with the idea that you can't pick your own password. The disclaimer is that I'm used to password managers. Edit: no wait this is terrible Space Kablooey fucked around with this message at 16:34 on Dec 14, 2017 |
|
#
?
Dec 14, 2017 16:30
|
|
|
Elman posted:
The only time when this is appropriate is when an account is created by an administrator and a "reset password" email is being sent to the user, to prevent anyone form logging in in the meantime. Otherwise ... hah.
|
|
#
?
Dec 14, 2017 17:21
|
|
|
Firefox raises an error if a function references an argument that is not part of its signature and was not passed into the function. Chrome does not and will happily execute the rest of the function anyway.
|
|
#
?
Dec 14, 2017 17:43
|
|
|
Pollyanna posted:Firefox raises an error if a function references an argument that is not part of its signature and was not passed into the function. Chrome does not and will happily execute the rest of the function anyway. Could you clarify what you mean here? It's perfectly normal in JavaScript to refer to variables that a function closes over but which are not formal arguments to the function. Internet Janitor fucked around with this message at 18:36 on Dec 14, 2017 |
|
#
?
Dec 14, 2017 18:31
|
|
|
Pollyanna posted:Firefox raises an error if a function references an argument that is not part of its signature and was not passed into the function. Chrome does not and will happily execute the rest of the function anyway. Can you post an example? This... doesn't seem right, even for the zany world of JS.
|
|
#
?
Dec 14, 2017 19:30
|
|
|
Now I’m not so sure. All I know is that a function that’s supposed to have event passed to it didn’t have it in its signature, but called preventDefault in the body. Chrome was fine with it, but Firefox broke.
|
|
#
?
Dec 14, 2017 19:45
|
|
|
You're not talking about event/window.event by any chance?
|
|
#
?
Dec 14, 2017 20:44
|
|
|
Yeah must be using event.preventDefault. window.event is non-standard (from IE) but I guess chrome supports it. FF does not. https://jsfiddle.net/z3o1ehkb/ https://developer.mozilla.org/en-US/docs/Web/API/Window/event Hilariously, the MS document link about that attribute redirects to MDN on Window.Event the class!
|
|
#
?
Dec 14, 2017 22:35
|
|
|
MS and Mozilla are working together to make MDN the default JS reference.
|
|
#
?
Dec 15, 2017 00:15
|
|
|
Pollyanna posted:Now I’m not so sure. All I know is that a function that’s supposed to have event passed to it didn’t have it in its signature, but called preventDefault in the body. Chrome was fine with it, but Firefox broke. Hah, oh yes. I've hit this one before.
|
|
#
?
Dec 15, 2017 01:31
|
|
|
|
| # ? Jun 5, 2024 13:28 |
|
|
 IE ruins things yet again.
|
|
#
?
Dec 15, 2017 01:49
|
|