Separate location

[cbbrowne]

Here is a "drafty" form of drawing location off of the main ship table to a separate ship_location table.

[Abstrct]

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
INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807
START 1
CACHE 1;

create table s (
id integer,
val integer
);
create table s_l (
id integer,
val integer
);
create view s_v as select
s.id, s.val sval, s_l.val as slval FROM s, s_l WHERE s.id=s_l.id;

CREATE OR REPLACE RULE s_insert AS
ON INSERT TO s_v DO INSTEAD (
INSERT INTO s(val) VALUES(NEW.sval);
INSERT INTO s_l VALUES(currval('s_seq'), NEW.slval);
) ;

CREATE OR REPLACE FUNCTION id_dealer()
RETURNS trigger AS
$BODY$
BEGIN
NEW.id = nextval('s_seq');

RETURN NEW;
END
$BODY$
LANGUAGE plpgsql VOLATILE SECURITY DEFINER
COST 100;

CREATE TRIGGER d_dealer
BEFORE INSERT OR UPDATE
ON s
FOR EACH ROW
EXECUTE PROCEDURE id_dealer();

-- Run each of these in a different process
INSERT INTO s_v(slval, sval) SELECT 1,1 from generate_series(1,1000000);
INSERT INTO s_v(slval, sval) SELECT 2,2 from generate_series(1,1000000);
INSERT INTO s_v(slval, sval) SELECT 3,3 from generate_series(1,1000000);

--Check to missmatched results
select * from s_v where slval <> sval
-- No Results were returned

[cbbrowne]

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:
insert into transaction (id, when, who) values (nextval('tx'), now(), 'my-user-name');

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.)

• select when from transaction where id = currval('tx');

"Oh, who's the user?"

• select who from transaction where id = currval('tx');

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() :-).

[Imran-imtiaz48]

This project demonstrates a solid understanding of PostgreSQL database design and PL/pgSQL development, particularly in the implementation of a game-oriented simulation environment. The schema design effectively separates concerns through dedicated tables for ships, fleets, locations, actions, and events, while the extensive use of triggers, views, stored procedures, and rules showcases strong database-centric application logic. The use of spatial data types such as POINT along with GiST indexes for proximity calculations is a notable strength, enabling efficient location-based operations. Performance considerations are evident through strategic indexing and optimization of frequently accessed entities. The codebase also incorporates automated workflows for ship creation, movement tracking, combat mechanics, resource discovery, and event logging, reducing application-side complexity. While the functionality is comprehensive, maintainability could be further improved through consistent formatting, enhanced inline documentation, standardized naming conventions, and modularization of larger procedures. Overall, this repository reflects advanced PostgreSQL expertise, strong knowledge of relational database architecture, and practical experience in designing scalable, data-driven systems with complex business logic.