First of all, sorry if this has been raised before…
One main pain point I’m having with assembling app components, is that db scripts are static… that is (correct me if I’m doing smt wrong) if I want my component to be used with a SQL Server db in a target app, I must myself generate db scripts specifically for that.
The same goes for Postgres, or Oracle, and so on…
This is not so practical… in your opinion, is there the possibility to postpone the creation of db scripts for components, so that they are built with the create/update database tasks on the target (consuming) app?
(PS: I realized I forgot to create db scripts for Postgres in my forgot-password component, and now I’m not able to use it in a project using Postgres I’m going to publish an update, but this is something I wish I could avoid in the future…)
We came across this problem too, and didn’t find an appropriate solution. For an app component developer to think about all databases and to generate scripts for them is obviously not ideal, if even possible.
I think your idea is brilliant, it will work for 99% of cases when app components do not require complex data initialization or non-standard types, etc. I’ve created an issue: https://youtrack.cuba-platform.com/issue/STUDIO-4082
I’m glad you find my idea useful…
If I may add to your comment:
when app components do not require complex data initialization or non-standard types, etc.
In that case, you could implement two strategies (both will be useful, for two different reasons):
- make the main create/update procedure call into extra sql scripts located inside the app component, so that if a component needs special post initialization stuff, it can simply provide a 3x set of scripts for various engines, much like today
- a standard entry point hook in app components, that could be resolved via reflection, and called after the “standard” create/update database procedure.
In this way, if the app component needs to do something special, not possible with plain SQL, it could do so inheriting the connection from the Studio procedure.
The same technique could be expanded in the future to support other “live” steps when first activating components in Studio (like other plugin systems do), but that’s beyond the scope of this discussion I fear…
The first point should be implemented right from the start IMHO, while the second must be carefully evaluated, because it opens up potential problems with bad written components that could harm Studio stability.
Maybe I miss something, but how does your first strategy differ from the current mechanism? Now if a component has a set of scripts for a database used in the app, they will be executed.
I mentioned it just to say not to abandon the current way of launching scripts for components, but do both things in sequence…
that is, generate component scripts dynamically at component setup in the host application, and then call into static scripts to do further init.
But, that post app init scripts remain static, so I proposed the second solution to hook into some java code, to generate sql dynamically…
Hope this clarify my point…
I see. Of course the current mechanism will remain.