-
-
Notifications
You must be signed in to change notification settings - Fork 373
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use PKs for cross-referencing instead of business/natural keys #1497
Comments
reservation, transaction, connector and charge_box are part of the CPO domain. I think the idea is good for connector and ocpp_tag because it is related to the same domain. But I'm less sure for reservation and transaction_start because of the difference of domain and data ownership. IMO, CPO domain should not have a strong dependency to the emsp domain and using the id_tag as FK allows to keep the expected data at the good place without breaking the current implementation. |
i think one potential problem is the following: since ocpp tags are not guaranteed to be universally unique, what if multiple EMSPs use the same value and therefore are in conflict with each other? using a natural key is a problem here. a transaction or reservation is not guaranteed to be in a universally unique relation with an ocpp tag id. the same can be said for charge box id. therefore, in general: natural keys are not guaranteed to be unique across different providers/worlds. |
moreover, current db models of reservation and transaction require a valid ocpp tag id FK, meaning: an entry has to exist in ocpp_tag table. if the entry has to exist anyways, this entry will have a PK. therefore, changing the reference from natural key to PK is just syntactical. |
If I understand well you say we need more information because the tag is insufficient alone, especially when there are many actors. |
FK removal? what would be the motivation and use case? do you have a fork of steve where you made some custom enhancements/changes which would be broken after making the changes of this feature request? |
There appears to be a discrepancy between the intended functionality of the charge/reservation tag, as seen from a CPO perspective, and the actual manageability of tags through the interface, as seen from an EMP perspective. This mixing of concepts is potentially problematic and could result in functional issues. However, it is important to note that this discussion is based on conceptual arguments rather than concrete instances in a production environment. |
Checklist
Describe the problem you are trying to solve
We are using a mix of PK and natural key references when it comes to cross-referencing between tables. A benefit of referencing natural keys was: They are there, whenever we need to use them. Additional resolution will be necessary with PKs as the men in the middle to arrive at natural keys. This was the primary motivation to leave them as is.
The following tables are subject for this problem:
connector
referencingcharge_box_id
ocpp_tag
referencingparent_id_tag
reservation
referencingid_tag
transaction_start
referencingid_tag
Describe the solution you'd like
connector
should referencecharge_box_pk
ocpp_tag
should referenceocpp_tag_pk
of the same table to express parent id tagreservation
should referenceocpp_tag_pk
transaction_start
should referenceocpp_tag_pk
Describe alternative solutions or features you've considered
Leave as is: Not a clean solution. Might block developing some features.
Additional context
...
The text was updated successfully, but these errors were encountered: