prc), but other options like session storage or user-specific caching might be preferable in your use case. So let's assume we have a variable called
mainDatasourcein our private request collection which has the datasource name we should use. We should be able to change the default datasource in every quick object just before it sends a query to the database.
instanceReadyevent internally and as an interceptor. We will hook in to this lifecycle event by creating a base component for our entities.
instanceReady()lifecycle method which fires AFTER an object is created, but before data is loaded from the database. We get the datasource from the private request collection, and only take action if it is set. If there is a value, we change the
_queryoptionson the builder object. Unfortunately this is not enough, because the
_queryoptionswill not be read again after
instanceReadyfires, so we explicitly have to set the default options on the _builder object again. Once that's done, your Quick entity is ready to query using your dynamic datasource. So every Quick entity which inherits from our custom base component will use dynamic datasources
newQuerymethod reads the default
_queryOptions, and prepares a query object. We create a base component again and this time override the
prcagain, and modify the
_queryoptionsto use that datasource. Once this is ready we can call the
newQuery()method of the parent object to finish setting up. Again, if your Quick entity inherits from this base, your quick object will now be using dynamic datasources.
preQBExecuteinterception point. By creating and registering an interceptor, you can change your datasource just in time. The interceptor can look like this:
quick.models.BaseEntity. Option 3 is less specific and might change your datasource in unwanted places. But if you know what you are doing it can be a very powerful way to add this dynamic datasource capability to Quick.