in my app I’ve stored all "dataId"s in partials and given them a default value of “00000000-0000-0000-0000-000000000000” because a default value is required by the system. I now get this warning about server side filtering that you can see in the screenshot. Does that mean server side filtering is not applied? And if yes, does that mean I cannot store my "dataId"s in partials if I want to use server side filtering?
this warning states that the necessary conditions for server-side filtering could not be validated, because it assumes that
00000000-0000-0000-0000-000000000000 is the actual data ID. Server-side filtering will be used anyway though if the data referenced by the partials satisfies the conditions (i.e. they have the PostgreSQL storage type). We will have a look how we can improve this warning in the future.
Can someone point me to the “best practice” that is storing datasource IDs in partials?
I’m interested in the reasoning.
Thanks a lot @matthias.fisch! Knowing that it will be applied if the necessary conditions are met is fine for me
@Flogge we do this to make our Dev2Prod easier. If you have existing projects for let’s say development, staging, and productive then you can copy your entire app code besides partials from dev to staging to prod without having to take the manual effort of switching the IDs everytime (datatables for example will have a different ID per project).
To be precise: we store everything that will differ from project to project in partials.
Thanks for the info. So basically, you use partials as variables here.
Thinking Dev2Prod, I might have an additional idea for automating the replacement:
I’ve created a workflow that takes a whole App JSON as input. The script contains data table name references in its comments (behind every data table ID), prefixed with a marker. The workflow dissects the script, extracts the data table names and looks them up in its own project. If suitable data tables are found, it replaces the IDs and reassembles the initial Script with updated data table IDs.
If someone is interested, let me know. The WF is under development but already yielded working apps. By having it in a project imported for the App’s backend infrastructure, the setup/update process of the app can be (semi-) automized.
Sorry for the (really) late reply!
The workflow is also a nice idea. Are you also able to replace other IDs like those for Production Lines and Workflows? What would be really useful (at least in our case) is also to be able to replace a prefix in the dataset or workflow name - that is how we distinguish our DEV and PROD resources that are located on the same instance.
About partials: using them as variables (I mean variables as we know them from other programming languages) is what they are for, right? At least I always thought you use app-partials for variables that are static and app-variables for variables that can change.
Currently, I’ve only hooked up Data Tables but technically it’s totally feasible to include WF and PL IDs in the lookup and I’m planning to do so.
Prefixing might be another optional extension and is doable for sure (don’t know if it’s actually needed since the lookup will be in the current project, only - so if you have dev and prod in separate projects, you should be fine. Depends on your project structure and resource naming, though).
On the usage of partials: I have complete “templates” in partials, e.g a table column formatting config which is 50+ lines. So yes, it’s like variables but not only single primitive values but also complex objects.
Nice! We are currently doing it via a python script but having it as a workflow directly in the project would certainly have its charms
Regarding prefixes I still think you would need them: If you develop something and then want to update your productive app you will copy the entire apps code (at least that’s the only way I know :D) and therefore would overwrite all comments with the PROD prefix with the DEV one.
Regarding partials: Agreed