Add my own key records to id generator? Generating presets for built on apps

pixelplumber

Hi. What is the best way to create my own id generator key definition (or really any data in a dependent app) for my app’s relations when it is installed?

I can’t create a preset for a relation in another app. Do you run a ‘once’ backend function to create a custom key definition in the underlying id generator app?

gabriel

Yes, if you want to populate data in apps that you depend on but which do not know your app (like the ID generator in this case), you would run a initialization function.

The ID generator is a very simple app - you could also choose to replice (e. g. copy/paste) its logic into your app. I prefer the first option, because reusing simple apps is usually easier to maintain. :)

pixelplumber

gabriel ok great will go with option one. Not much in builder docs on schedules but your great backend functions YouTube video says ‘once’ functions run every app update or server restart? So have to be idempotent?

For setting up another app’s data would you tend to check for the record presence directly each time or set a flag in a config relation on your own app after successful setup and return early in subsequent runs?

I’m wanting to create unique identifiers for individual caller ID records so we can sanitise callers’ real numbers for privacy reasons while still allowing reporting exports to csv.

gabriel

pixelplumber
Functions with a once schedule run 'once' - so they are never repeated, not even when an application updates or the server restarts. If you remove the once schedule and create a new one, it will run again - but again, only once ;)

So with a once schedule, you do not need to worry about blocking repeat execution. But in general, yes, I would use a relation and store/update a value to check on the next run and abort the operation if it was already done.

Regarding unique identifies - for this purpose, the UUID type is especially useful, which can be automatically created as default values on record creation, or later via backend functions.

pixelplumber

gabriel ah, sorry I misunderstood what you were saying at 24min 50sec into the video as running the function 'once per update/restart' vs 'once at the next update/restart'. 😄

pixelplumber

gabriel just curious how do you check and reset the once functions during development? Are you just calling the migration or update script as a backend function manually or with a schedule until it’s perfected and then setting it as once for deployment?

Or is there a way to reset its status when you test an import (haven’t gone hunting in the db for a flag yet)? Or do you have to delete/copy to a new function to run it again in a testing/staging instance?

gabriel

pixelplumber
Generally, we use once functions for migrating data because of changes to relations. For testing, we manually run the backend function (as you´ve guessed) until we´re happy and then finally set the schedule.

For larger migration scripts, I usually prepare a test DB and a reset script, to get back to the original DB state, in case I need to adjust and try again.

pixelplumber Or is there a way to reset its status when you test an import (haven’t gone hunting in the db for a flag yet)? Or do you have to delete/copy to a new function to run it again in a testing/staging instance?

Yes, you can update the corresponding record in instance.schedule - setting the date_attempt / date_success columns to NULL makes the scheduler re-execute the function in your current instance. But you will need to restart the service.