"Show All" madness
-
I get the impression we're missing some detail required to clearly identify the real WTF here, whether it's user-based or otherwise.
-
-
one criteri
aon.*twitch*
-α is plural neuter, not singular feminine in this context.
Singular neuter is -ον.
Mod - PJH. Ok, since you lot can't decide on which badge, I'm going for pedantry.
-
twitch
-α is plural neuter, not singular feminine in this context.Singular neuter is -ον.
Close. That word (like most) doesn't have gender in English.
-
Close. That word (like most) doesn't have gender in English.
That's why I wrote the Greek suffixes. The English word is derived (transliterated even?) from the Greek word.
See also: phenomenon
-
That's why I wrote the Greek suffixes.
I noticed that, and it was weird, too, since they only sorta matched what you were replying to.
-
I could have done what I did in http://what.thedailywtf.com/t/unicode-making-life-difficult-again/4720/74?u=offbyone for extra weirdness
-
winnar of spellar/gramming flag!
and if enough people agree you might just win a badger too!
-
You know you've been at TDWTF too long when you take devil's advocacy so far you argue for Blakeyrat's presumed side.
Also: will they actually swap your battery, or just tow you to a garage/Autozone/dealer?
They will swap it out on the spot.
They've got special non-towing trucks for jump starts and the like - and they've got extra batteries.
-
They will swap it out on the spot.
They've got special non-towing trucks for jump starts and the like - and they've got extra batteries.
Interesting. I never knew that.
The last 2 times I needed a new battery, the most recent, I knew it was going so I drove to an auto parts store before it died. The time before that, the car refused to start at work, and I got a coworker to take me to a parts store so I could replace the battery. Which reminds me I'll probably need to replace it next month, because it's about that time.
-
Interesting. I never knew that.
AAA in Virginia/Maryland/(DC too I suppose) had this as of 1+ years ago. YMMV.
-
AAA in Virginia/Maryland/(DC too I suppose)
add Maine to that list. they send out that truck for everything that does not require a tow.
headlight replacement to spare tire to even just winching you out of a ditch (about half the trucks have a winch on them)
-
It's been a long time since I had AAA, so that's probably why. I don't think my insurance would do all that--but I do have towing/jump/gas service, and that covers approximately all of my use cases to date.
-
winnar of spellar/gramming flag!
For the Greek suffixes? He/she's probably only one flag away then... :<qq>D
-
-
Wrong. What you do is take that modal dialog you had and add a progress bar to it.
I'm going to give the OP a benefit of the doubt and assume that he's not TRWTF and updating 1500 records is indeed a lengthy process. But still, they want to update 1500 records. What way could there be around it?
The complaint was that the page was "stuck". Well, make it appear not stuck, matbe? Make a progress bar, abstract lengthy updates to background jobs which leave the rest of the site usable, or even show an ETA so that they know it's gonna take long.
First there was the page that stared back.
And people thought it was stuck.
Then there was the popup modal with text.
And people still thought it was stuck.
Then we added a progress bar.
And people got used to that, and now still think it's stuck.
Then we added an item/total display.
And one of the items was larger than the other.
And people are complaining that the process isn't as efficient for each item.So, now we just have them request a search, then call them back when the results are done calculating.
-
-
-
PCTFY
is that still politically correct if we already know @OffByOne's preferred pronoun? (which is the one i used there)
I'd say no it isn't.
-
If that's the case, why is this process synchronous with the webpage display.
Just say the updates will occur in the background and batch update.
-
I think the correct term is "one".
One does not.
This one does not.
-
We shall not let xem impose heirs black-and-white vision of zeirs gender upon us!
-
-
I think @Maciejasjmj got sent to some kind of weird sensitivity
trainingreeducation.
-
i don't think it worked then
-
-
is that still politically correct if we already know @OffByOne's preferred pronoun? (which is the one i used there)
I'd say no it isn't.
I'd say it's not correct (politically or otherwise), but incorrect.
You can refer to me with masculine pronouns. Otherwise my username would probably be OffByOnα or even OffByον ;)
-
*twitch*
-α is plural neuter, not singular feminine in this context.
Singular neuter is -ον.
Mod - PJH. Ok, since you lot can't decide on which badge, I'm going for pedantry.
-
Mod - PJH. Ok, since you lot can't decide on which badge, I'm going for pedantry.
Do you want me to create a poll?
-
Do you want me to create a poll?
Not really.
I've got enough work on without waiting for discourse to take 3 minutes to load the /admin/users/USER/badges page to swap the badges if it would need changing....
Really should report that as a bug over on meta...
-
Really should report that as a bug over on meta...
https://meta.discourse.org/t/unresponsive-script-on-admin-users-user-badges/23732
Viewing raw may be educational...
-
Viewing raw may be educational...
Of what post exactly? I can't find anything interesting, let alone educational in the raw of the posts in this thread I looked at.
Raw on meta.d doesn't work.
-
-
Really should report that as a bug over on meta...
Somewhat related (same page, at least):
Badges not sorted in Grant Badge dropdown
When granting a new badge to a user (admin/users/$user/badges), the badges aren’t sorted in any apparent order. I expected some sort of alphabetical sorting, but that doesn’t appear to be the case. Neither are badges in the same group put together, which is another sorting candidate.
-
I'm going for pedantry.
I think this is the right call—it's the impromptu Greek lesson which elevates it beyond mundane spellar/gramming.
-
I've had stuff where a cow-orker tried to do something similar by using hibernate and iterating over the objects, doing stuff, checking things, then saving each one. This takes for fucking ever. Because you go back and forth to the DB a zillion times.
Change to make the work happen in one or two queries and suddenly minutes to hours takes seconds.
I've recently had to make a change in the opposite direction: A query to return a few thousand objects in Hibernate took too long because Hibernate hydration of complex object graph so the client was timing out. Made a native query to return a list of IDs instead which takes only seconds, then use the ID to hydrate and process one at a time. There is some output for the processing of each object so the client doesn't time out. The whole thing probably takes a bit longer overall than it otherwise would, but it's an unattended batch job so that's less important.
-
Over and over, I see this pattern. Everyone says they love ORMs, yet what they really seem to mean by that is that they don't like writing the mundane stuff for converting between an object and a row (which might be in a table or view or whatever). Anything more complicated at all, and the ORM switches into getting in the way of actually getting work done…
Yes, I know about HQL and the like. I'm not convinced that it helps relative to learning and using SQL itself.
-
I just outright say I hate ORMs and don't use them.
This company I just got hired at does the same. Awesome. EDIT: also free fruit snacks.
-
they don't like writing the mundane stuff for converting between an object and a row (which might be in a table or view or whatever)
That's pretty accurate. I've used ORM-ish libraries that are much lighter weight than Hibernate and they give most of the value that Hibernate does. We do use some more advanced features occasionally and they're pretty neat but that's not where the greatest value lies.
Occasionally it gets in the way but overall it's much better than writing a bunch of SQL and setFoo(resultSet.get("foo")). All that manual loading and saving code is mundane and error-prone to write and updating it when the model changes is just painful.
Our normal use-cases are to load one object graph at a time for users to mess with and it works pretty well for that. Hibernate isn't really suitable for batch processing in most cases and it doesn't pretend it is.
-
EDIT: also free fruit snacks
Score!
We just got this a few months ago. Previously was just tea, shitty coffee and biscuits and I don't drink tea or coffee, shitty or otherwise.
-
Yes, I know about HQL and the like. I'm not convinced that it helps relative to learning and using SQL itself.
I don't think it helps relative to learning SQL. Has anyone ever claimed such a thing? When the query isn't too complicated, it's incredibly convenient, however, to get get a list of proper objects to deal with.
All that manual loading and saving code is mundane and error-prone to write and updating it when the model changes is just painful.
Yes.
-
I don't think it helps relative to learning SQL. Has anyone ever claimed such a thing? When the query isn't too complicated, it's incredibly convenient, however, to get get a list of proper objects to deal with.
Yeah, but that's more often a mark of just how bad the default mapping between SQL and the other language is. JDBC is a “shining” example in this regard. (Well, it glows by the light of its decomposition…)
-
Over and over, I see this pattern. Everyone says they love ORMs, yet what they really seem to mean by that is that they don't like writing the mundane stuff for converting between an object and a row (which might be in a table or view or whatever). Anything more complicated at all, and the ORM switches into getting in the way of actually getting work done…
Yes, I know about HQL and the like. I'm not convinced that it helps relative to learning and using SQL itself.
Have you looked at SQLAlchemy lately?
That's pretty accurate. I've used ORM-ish libraries that are much lighter weight than Hibernate and they give most of the value that Hibernate does. We do use some more advanced features occasionally and they're pretty neat but that's not where the greatest value lies.
Occasionally it gets in the way but overall it's much better than writing a bunch of SQL and setFoo(resultSet.get("foo")). All that manual loading and saving code is mundane and error-prone to write and updating it when the model changes is just painful.
Pretty much. Most ORMs make the mistake of assuming that databases are table-collections, which is quite untrue, and the cause of 99.999% of the ORM hatred out there, at least in my eyes.Yeah, but that's more often a mark of just how bad the default mapping between SQL and the other language is. JDBC is a “shining” example in this regard. (Well, it glows by the light of its decomposition…)
Agreed here -- SQL tends to have a massive impedance mismatch with imperative programming languages in typical database APIs. Why does nobody want to fix that? Beats me...
-
Pretty much. Most ORMs make the mistake of assuming that databases are table-collections, which is quite untrue, and the cause of 99.999% of the ORM hatred out there, at least in my eyes.
I've never used an ORM where the DB wasn't table collections. I still have plenty of reasons to hate ORMs. But they're still worth using.
-
Have you looked at SQLAlchemy lately?
No, because I don't Python.
But now that I've looked through their tutorials… it seems like a lot of effort to go to to avoid using SQL.
What is really being gained here that isn't obtained by just presenting the columns in the result set as a dictionary?Answer: [spoiler]the cross-links to other tables referenced by the columns with associated foreign key constraints are converted into references to other objects.[/spoiler] I've never been convinced that that's really worth the amount of effort.
-
What is really being gained here that isn't obtained by just presenting the columns in the result set as a dictionary?
Take another look at their SQL Expression Language...SQLAlchemy starts off by being very good at turning SQL (either as the expression language, or as text) into dictionary-result-sets, and then builds an ORM atop that facility. This has the benefit that it can do things like slurp the results of any old query in and convert it to the appropriate objects, for one -- for two, SQLAlchemy's expression language can pull off things like inverted column specifications (I want everything but X, Y, and Z) in a robust way, which isn't possible in straight SQL.
-
Take another look at their SQL Expression Language...SQLAlchemy starts off by being very good at turning SQL (either as the expression language, or as text) into dictionary-result-sets, and then builds an ORM atop that facility.
Like I said, I don't Python, so my skimming of things can miss stuff like that.
@tarunik said:This has the benefit that it can do things like slurp the results of any old query in and convert it to the appropriate objects, for one -- for two, SQLAlchemy's expression language can pull off things like inverted column specifications (I want everything but X, Y, and Z) in a robust way, which isn't possible in straight SQL.
Would that still fetch those columns? If so, what's the point? You're still paying the piper, yet you're not calling the tune.Generally, inverting the set of columns in the result set is awkward because negation is messy in intuitionistic logic where there's a potentially open world; you're asking for all the possible things that there might be (including the concatenation of the names of the first-born green-painted pantyhose wearers that are third cousins of the person identified by the row) and that's an unbounded set (even if those are actually empty relations). It's not like classical boolean logic where everything is true or false: you've got the things you know to be true, the things that you know to be false, and the vast sea of the genuinely unknown.
Like I said, I don't like ORMs very much. They really don't buy you very much other than in languages like Java (JDBC is pretty miserably low-level as a DB binding layer). People funnel vast amounts of effort into making the ORM work, but frankly they'd be better off just learning to use SQL itself right (and fixing the real binding layer to not hate people so much ;)).
Now get of my lawn…
-
Would that still fetch those columns? If so, what's the point? You're still paying the piper, yet you're not calling the tune.
No, it wouldn't -- SQLAlchemy can read table schemas in from the database.
(and fixing the real binding layer to not hate people so much ;))
Python DB-APIs aren't nearly as irritating as JDBC AFAICT (but I have only worked with JDBC via its Clojure bindings...), its just that they work slightly differently depending on which DB you're targeting, ofc....SQLAlchemy is valuable enough already for compensating for the variety in SQL implementations -- the ORM is just gravy ;)
-
Python DB-APIs aren't nearly as irritating as JDBC AFAICT (but I have only worked with JDBC via its Clojure bindings...), its just that they work slightly differently depending on which DB you're targeting, ofc....
SQLAlchemy is valuable enough already for compensating for the variety in SQL implementations
I've seen two schools of thought there. One is that the differences in SQL dialects should be concealed so that code can be retargeted with minimum effort, and the other is that all the warts should be exposed so that advanced non-portable features of DBs can be actually used. I can see both sides of the argument, but slightly prefer the warts approach: less code in the binding layer means less to debug when things don't work as expected. ;)
Of course, it makes moving between DBs harder, but how often do you really do that? And all the data too?
-
SQLAlchemy lets you do things either way, or even mix the two techniques any way you so please...heck, you can even take the connection pooling system and use it independently of the rest of the library!
