Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Separate location #12
MOVE_SHIPS() is going to need to update location, speed and direction. So those are the columns I would assume we want to be together. Target_speed, target_direction and destination are all user updatable so they would be best in their own table (ship_control). This should allow MOVE_SHIPS() and SHIP_COURSE_CONTROL() to be run at the same time without deadlocking.
I wonder if it is the right thing to "insert to my_ships."
It seems to me that this will require increasing amounts of cleverness as attributes get added.
I'm finding I want to do multiple inserts (e.g. - need INSERT INTO ship(), INSERT INTO ship_location (), possibly more...), which doesn't seem to work very well.
Probably what has to happen is for this to be refactored into some function calls.
Thus, something more like:
CREATE OR REPLACE RULE ship_insert AS ON INSERT TO my_ships DO INSTEAD
Suppose create_ship() returns the new ship ID, then we want...
perform locate_ship(create_ship(parameters), location);
That works if the ID is only used once. If there turn out to be two functions that require the ship ID, then it all has to get wrapped together. Perhaps that simply means that create_ship() does everything, and maybe there's no need for a trigger on ship.
Hmm, good points about the ship's ID. I am going to have to play around with this and see if we can find a reliable way of tossing the ID around between tables or storing the initial location somewhere in a column like.. initial_location or which planet the ship originated from (this may limit future development though if ships can one day be created at somewhere that isn't a planet).
I was a bit worried about currval(seq) due to the way ID's are handled in the game but I just gave some code a go to test it and there were no complications. There is no reason why we cannot trust currval('ship_id_seq) in the insert into the ship_location table during the my_ships view insert rule.
CREATE SEQUENCE s_seq
create table s (
CREATE OR REPLACE RULE s_insert AS
CREATE OR REPLACE FUNCTION id_dealer()
CREATE TRIGGER d_dealer
-- Run each of these in a different process
--Check to missmatched results
There is an alternate perspective of "currval" which involves the function returning the most recently generated sequence value from ANY sequence associated with your DB connection.
Which is perhaps the most terrible behavior possible; it means that if you decided to (say) replicate Schemaverse using Slony or Londiste, you might instead capture sequence values being used as part of the internals of those replication systems. Horrible, horrible, horrible.
(Poking at docs...) Ah, the function that does this is lastval(). http://www.postgresql.org/docs/9.1/static/functions-sequence.html You'd have to be insane and stupid to use lastval() for anything.
But if you use currval('specific_seq_name'), it's all good.
A couple years ago, I was working on an experimental domain registry prototype where we were using currval() extremely heavily to establish transaction contexts. Basically, we'd create a logical transaction:
and then, throughout the rest of the DB activity, HEAVY use was made of currval('tx') to reference the transaction context data.
"Oh, what time are we using for this transaction?" (It didn't have to be NOW() - it was meaningful to backdate/forward date activity.)
"Oh, who's the user?"
We'd attach all kinds of additional data to the transaction by joining in extra tables; the key to getting at it was always currval('tx'). And this worked out AOK. I have a fair bit of faith in currval() :-).