[VUE 3] Calendar multiple event stores using CrudManager

[cm_devnick]

Hi there!
I'm trying to definitively figure out if it's possible to have multiple event stores using the crud manager in the calendar.
Specifically, we have three different data sources that I'm trying to avoid bulking into one endpoint response, i.e. a separate endpoint for each event store.
This is while using the crudmanager and one instance of the calendar. We'd like to be able to show all data from all three sources in the calendar, so we're trying to avoid having one store per instance of the calendar and having to flip between them to see all three data sets.
Thanks!

[mats]

Hey there, and welcome to the forums!

This is not supported I'm afraid. Our Calendar assumes there is a single EventStore currently. So either:

1) Load all events from your different sources in one endpoint as you said

2) fetch from 3 endpoints manually and call eventStore.add() once when you've collected all

Are either of these options ok for you?

[cm_devnick]

Thanks! Glad to be here.
Ah great. This aligns with what we were suspecting!
So we're currently trying the second approach.

• 3 stores with readUrls that autoload
• 1 store with no read url, but does have an update url
  After the 3 stores get their data, we call mergedStore.add() on each data object in the 3 stores

Here's where the new questions come in:

1. When I supply the mergedStore as the eventStore to the calendar config's crudManager, with no other config options in the crudManager, when the sync is called after I edit an event, the request payload only has an id and name in it. So I have no way to tell the backend's update endpoint which table this record belongs to and where to write the update to.
2. To try to solve the above issue, we also tried removing the update url from the store, and instead include it in the crudManager as a transport with autoSync on. The problem here is that the payload, while it does have more data and can take custom fields, has every event model in the payload, not just the updated one.

Any advice around this issue? What am I doing wrong?

And tangentially, I am curious if doing it this way, and more specifically doing it like I'm attempting in my first point above, is circumventing the crudManager's ability to manage things, so we're losing out on the benefits of the crudManager.

Thanks!!

Edit: An extra question:
If we're using the CrudManager, do we have to load all the data on load, or is there a way to load on demand based on where we are in the calendar?

[Animal]

Probably the best solution would be for you to write a wrapping backend service which aggregates the underlying three event sources and produces a response block which the CrudManager can use.

The difficulty there would be writing the sync service. The events being sent back for syncing (either removal or modification or addition) would have to be marked to indicate which final end point should receive the request. The events would have to be separated out, and sync requests passed to each of the three event sources. Then the responses from those similarly aggregated into a sync response for the CrudManager.

If you can create that reliably, you could simply use the LoadOnDemand feature which includes a start date and end date parameter with its requests, and loads itself whenever a new date range is required (When moving forwards or backwards in time, or when changing to a view with different range)

[cm_devnick]

So I added the writeAllFields field to the crudmanager and that solves the issue of having more than just the updated fields included in the payload, and using that I can check a property that we passed along with the data to know which db table it came from. So syncing it to the right place when it hits the update endpoint isn't actually an issue anymore. A bit not ideal, but we're working with what we got.

RE: the loading on demand, I was attempting to implement it, but was hitting some errors then saw in your documentation that it's not available for the Calendar. Is that correct? I also didn't see an inherent way for the crud manager to automatically manage the loading on demand, I had to hook into the date range changed event, and then call the endpoint myself to get the new data then sync it to the merged store myself. Which then made the initial stores semi redundant, and I could just call the endpoints directly and not need the stores, which then made me wonder if I needed the CrudManager if I was doing all of that overhead myself.
Maybe I'm missing something though (probably am).

Thanks.

Edit: My mistake. What is not supported by the calendar is LazyLoading.
LazyLoading is currently not supported in Calendar, Gantt nor TaskBoard. as per the documentation. But I believe this works in tandem with the LoadOnDemand flow to allow for loading using pagination, correct? So if we're using the CrudManager, we have to load the entire data payload afaik.

[Animal]

There can be no pagination. There are no pages. There can be no laziness.

That concept has to do with Grids. (And remember, Scheduler is a subclass of Grid).

When scrolling a large Grid dataset, the store is able to load the data as it is demanded by scrolling. That concept does not apply in calendars.

The resources which apply to an event dataset, must be loaded with that event block.

The LoadOnDemand feature will work for you if you have a backend which is able to aggregate your event datasets and create a data block containing all events, resources and time ranges needed.