Closed nliaudat closed 4 years ago
Thanks for raising the issue, I had the same concern when discovering the extension concept. IMO Solution 3 is the best. We need also to include unit test about value lists :
@elemoine @lbartoletti @3nids @sylvainbeo Any opinion here?
@nliaudat please contact us if you need that to be adressed.
Régis
As I experienced for Pully's customizations, the more separated it is, the best it will be for general integration and keeping up with main code branch.
Actual situation of SIRE extension is more historical than a proof of concept.
My personal opinion is that the ch_fr_aquafri extension could be implemented in the same way as the ch_fr_sire extension for now, until a better design is figured out and implemented for extensions. In other words if including ch_fr_acquafri extension makes sense to the QWAT community I would not block its inclusion because the current extension design is not perfect. That being said I'd also put a big priority on fixing the extension design.
Here it is :grin:
https://github.com/nliaudat/ch_fr_aquafri
That solution is working for now in my job. Not perfect, but can be customized.
Regards
@haubourg : unit test :
1) ensure core value lists are ok compared to a reference
Done with a subset of queries
SELECT A.id, A.value_fr, B.id, B.code FROM qwat_vl.precision as A FULL JOIN qwat_ch_fr_aquafri.precision AS B ON (A.id = B.id) WHERE A.id IS NULL OR B.id IS NULL
but must be performed by hand
2) ensure that migrations lead to a good value list set (including user customisations, extensions)
not sure ... all inserted values have an id greater than 10000. Is that enough ?
3) ensure that "unloading" an extension will delete additional value list
Dangerous, can break record integrity
@nliaudat @haubourg @lbartoletti I think we should have
https://github.com/qwat/ch_fr_aquafri https://github.com/qwat/ch_fr_sire ...
as known QWAT extensions with maintainers having rights on theses repos.
Efforts are now mainly on QGEP but as soon as QGEP works we will be able to tackle these.
But I'm aware that the sooner the better since SIRE deltas are now mixed in QWAT delta which is not what we want.
as known QWAT extensions with maintainers having rights on theses repos.
I'd be +1 on this, though we need to set up a code review process tho ensure quality (as always in open source projects). I'm unsure how to fund that. Could that be taken into the helpdesk process so that merging PR's could be done fast enough to let contributors jump in? This is exactly why we landed to a separate repo by @nliaudat It's a topic to be raised to the general steering comittee. cc @vpicavet
+1 or simply add it to existing qwat-data-model/extensions
@nliaudat You should have permissions on the new dedicated repository for AquaFri extension : https://github.com/qwat/extension_aquafri
You have to change files in the extension folder. Let me know if it's good for you.
I close this issue.
Hi, I plan to make a new extension forked from "ch_vd_sire" for Fribourg's Aquafri datamodel.
I have some question on how to do that, cause sire's one is a mixture between extension and hardcoded values in qwat base datamodel
As example, all views are on a separate schema "qwat_ch_vd_sire" but all values are hardcoded in qwat_vl with an additionnal "code_sire" field.
Solution 1 : Add a new field "code_aquafri" like "code_sire" ? I think it's not really the best way, cause the number of extensions could grow (26 cantons, foreign,...).
Solution 2 : Reuse existing "code_sire" field (perharps renaming it export_code"). Not good if I need two extensions simultaneously
Solution 3 : Make correspondance tables in extension's schema. As example : ch_fr_aquafri.pipe_material containing the id from original qwat_vl.pipe_material and field "code"
What do you think about ? Regards Nicolas