How big is the actual dataset? I know you mentioned a test file download was similar in speed between the locations, but 350k rows could end up just being a lot of bytes and you’re getting constrained by download speed.
I am not an expert but it sounds like you need a source of truth. Db’s make good sources of truth, usually. If the db has a publish/subscribe feature (most do) that could be what you’re looking for? As stated I’m a little confused what you’re trying to do.
2 Likes
If you have a single page app like react and you do something like publish a new row (like say a post on a forum) the javascript will just put what they “know” the db will have in there without waiting for a request/response, in 95% of cases. It will just do an xhr and if there’s a 200 it will do nothing, is how most people do it.
1 Like
Thanks all for your thoughts. I can’t post it all here as it’s just too much…seems to me
is probably about it. On a site I have that is React (so it’s mostly javascript/client-side), it’s not crucial if
has quotes around it or not and I want people to be able to make a bunch of changes and not have any delays it seems best to “know” the db and javascript are in sync. For something that I don’t even mind a reload, is important (ie real world things will happen - money change hands - information get passed onto third parties), there’s not a ton of JS and it could easily get kind of lost/detached/maintained by different people down the line it seems like a
being the DB and never showing data that isn’t confirmed after each change sounds right.
There’s a series of essays I really like centered around the idea of an ur-datatype called Location that offers unconditional, infallible reads and writes. The upshot is that Locations are inherently subject to data races, so either you have to make one or the other of reading or writing a fallible operation or else deal with the resulting races. In the web context, if you’re always showing the current state on demand, and you’re showing the user their writes, then you’re effectively offering a Location interface, which means you can have data races. In order to avoid that, you need to check with the db before you commit writes so that you have an opportunity to reject the write if something has changed.
Now, depending on the business logic, the race condition might not really matter. For example, in an internet forum, the only race-y thing is that new posts can appear in a thread while you’re writing a post, but no one really cares about that. Or you lose a new post because the front end showed it to the user, but really it got lost in the internet. But if you’re doing the interface for a stock broker, it would be very bad if you showed a trade as having occurred before the server committed the order, which is why you have so many confirmation screens.
I think the most important thing is to figure out what the possible data races are and then figure out what the business rules are about how to resolve them. For pretty much any situation, if you show the action being completed before you get the 200 response back, there’s a change that the action fails to go through and you’ll need to communicate it to the user somehow. Or maybe they close their browser before you tell them about the problem and go on a six-month meditation retreat to Tibet–is that a problem? And depending on your use-case, there might be more complicated causality violations like write skews and phantoms and all that other database theory stuff. Like, what happens if user A and user B both see a particular state and make conflicting changes based on what they see? Or user A makes a change that appears in the interface but doesn’t go through, then makes a change that’s logically dependent on the first change and that one does go through? Or what if the user makes a change to Object 1 that appears to go through but doesn’t really, then they make a logically dependent change to Object 2 that does go through?
Ultimately, the level of data consistency that your users get is a business rule, not a design choice. I think you need to segregate the question about what the business rule is from concerns about maintainability and UX and address them separately.
This part seems a little concerning though:
This has led me to sometimes having to come up with ways to pass info between db and javascript using the path and hidden form elements so that the presentation can be right (like having the correct choices on a form selected/highlighted).
I’m not sure I fully understand what you’re doing concretely, but it seems messy to be running presentational stuff through the backend rather than keeping track of it locally.
1 Like
By “presentation” I just mean the data that’s presented. I don’t store JavaScript or CSS or html or whatever in the DB. I might be doing something a little funky using the path instead of the data more directly.
There’s some complication because there are modals that pop up and it seemed silly to go to the db to fetch info that I already had after some user actions that affect what’s in the modal, but could not change the data. So the logic of what to display there is client-side and that “passing” is just giving the client some data that is available, but won’t necessarily be needed.
I think that’s pretty ok. Not sure though, I could refactor that and generate the html for (in this case) 10 different dumb modals as opposed to one “smart” modal and just make the right one visible.
s/month/day/g (change “month” to “day”)
Whatever is feeding that “:months_ago” will have to feed it “:days_ago” instead or you could probably keep using :months_ago and have it be confusing.
Maybe.
wait…correction incoming
WHERE p.created_at >= DATEADD(DAY, -n, CURRENT_DATE)
Been a while since I used SQL so not 100% sure.
1 Like
this I think
(not that sumey isn’t also right, but it seems easier to slip this change into place)
(eta: if you’re just doing a query straight on the db, prolly what sumey said, and if you are just doing a temporary hack on the website code, you might want to leave :months_ago alone, since that is a variable coming from somewhere else and you’ll have to trace that if you want to change/add :days_ago. )
1 Like
I’m very rusty with this stuff, but why do we need a temp table with period start and end and then a join?
Why not just put it in a where clause?
Edit: just seen why in your comment after the code.
Set :days_ago to x.
I think that line is just a comment.
Probably get rid of the dashes (or is it an em-dash or whatever?). You may need to get rid of the “int” as well or maybe not.
Or if this is really just a one-time kind of hack you can just replace “:days_ago” with the actual number in the query.
DATEADD is SQL Server syntax, it won’t necessarily work on other flavours of SQL. I think they’re trying to use ANSI SQL to do it (INTERVAL is in the standard), which it why it looks so unreadable and why different flavours of SQL add their own less-horrible date manipulation stuff.
1 Like
I’m easily swayed so I put gVim on my desktop. I don’t know if it will help my repetitive stress issues but I’ll try anything at this point. I last used vim >20 years ago. Any suggestions as to what’s useful in vimrc? So far I have
colorscheme slate
set guifont=Monaco
set number
setlocal spell spelllang=en_us
set laststatus=2
A cool thing I recently discovered is
:colorscheme
and then tab through options.
About a week ago I really started using visual studio, but I have the Vim keyboard shortcuts set up.
1 Like
Gotta be honest I have no idea what someone would do with this
Obligatory “yo dawg we heard you like _____ so we put ______ in your _____” meme goes here I guess.
2 Likes
maybe testing?
Can you run a browser in the OS that’s running inside your browser?
You should be able to run a script that generates an electron app in that thing that then makes another electron app that…