#7 Implement relationships

Open
opened 2 years ago by otremblay · 3 comments

Foreign key constraints?

Get collection for a given item?

Map those to urls automagically?

Foreign key constraints? Get collection for a given item? Map those to urls automagically?
otremblay commented 2 years ago
Owner

kinda blocked by #5

kinda blocked by #5
otremblay commented 2 years ago
Owner

select * from information_schema.key_column_usage kc inner join information_schema.referential_constraints rc on kc.constraint_name = rc.constraint_name inner join information_schema.columns tc on kc.column_name = tc.column_name;

This gives all the informations to get from table A to table B. If we don't care too much for constraints because it will be dealt with by #5, we can in principle just have a function refer the remote table.

We're gonna run into problems if Table A refers to Table B, and Table B refers to Table A; we may need to pull back all the db package together again instead of the clean split we had before, because circular dependencies. In go land, it makes more sense that way anyway. It MAY make sense to pull the models out of the DB code, that way you wouldn't need to pull the db code in if you're only interested in the models, which is practical for when you want to only marshal models, for example. LET'S MAKE THAT AN ISSUE I'm never getting this project done, dear god. -_-

select * from information_schema.key_column_usage kc inner join information_schema.referential_constraints rc on kc.constraint_name = rc.constraint_name inner join information_schema.columns tc on kc.column_name = tc.column_name; This gives all the informations to get from table A to table B. If we don't care too much for constraints because it will be dealt with by #5, we can in principle just have a function refer the remote table. We're gonna run into problems if Table A refers to Table B, and Table B refers to Table A; we may need to pull back all the db package together again instead of the clean split we had before, because circular dependencies. In go land, it makes more sense that way anyway. It MAY make sense to pull the models out of the DB code, that way you wouldn't need to pull the db code in if you're only interested in the models, which is practical for when you want to only marshal models, for example. LET'S MAKE THAT AN ISSUE I'm never getting this project done, dear god. -_-
otremblay commented 2 years ago
Owner

Pull out the method signatures in a dbi package as interfaces. Pull out model definition to that same dbi package. From the implementations, refer to the interfaces of the other tables. Voilà, relationships.

Pull out the method signatures in a dbi package as interfaces. Pull out model definition to that same dbi package. From the implementations, refer to the interfaces of the other tables. Voilà, relationships.
Sign up for free to join this conversation. Already have an account? Sign in to comment
No Milestone
No assignee
Loading...
Cancel
Save
There is no content yet.