I need to represent the time in Swallow as *something*, and while some of the times are expressed in half-minutes relative to midnight (it's not as bad as it sounds), I guess I'm probably just going to use unix time in seconds for the sorting
-
Show this thread
-
Schedules as loaded are in half-minutes since midnight, flat schedules are seconds since the epoch. I'm now using server-side stored procedures and functions, and I'm still a bit undecided on how to feel about Postgres.
1 reply . 0 retweets 2 likesShow this thread -
For a location query, this needs five inner joins, one inline select, and this is without train running information, which I suppose would necessitate another join. databases are fun!
1 reply . 0 retweets 2 likesShow this thread -
Narrowly avoided a bug which would have lead to every train in the database having the same origin and destination, and now I'm curious about what that would be
1 reply . 0 retweets 3 likesShow this thread -
13:22 <Niya> on the bright side, it's now running extremely efficiently until it dies
1 reply . 0 retweets 1 likeShow this thread -
Everything's more or less as efficient as it needs to be, so the next order of business is either writing my own cursor or just dealing with the abomination of a query I'll need otherwise, because psycopg's dict cursors can't deal with duplicate column names
1 reply . 0 retweets 2 likesShow this thread -
A location query will entail at least seven joins, for around 40-50 columns. I *really* don't want to have to reference this by index .-.
2 replies . 0 retweets 1 likeShow this thread -
52 columns, and I'm doing it by index
1 reply . 0 retweets 1 likeShow this thread -
-
So the database maintenance script tries to delete most of the schedule records and I have no idea why, which means I need to insert vague prints everywherepic.twitter.com/KzGy8oGruG
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
