Hello all,

When persisting reference data in the database, I have no problem with using a static entity when the dataset is relatively small e.g. tax categories.  However, when the dataset is large e.g. countries it is a lot of manual effort to load the data.  My investigations so far suggest that I should create this as an entity first, bootstrap the data in, convert to a static entity, and then add any new records manually thereafter.  I have two questions:

1.  What is the benefit of converting the entity to a static entity for this type of data ?

2.  Are there any other options that I can consider ?

Many thanks,

Richard.

Solution

Hi Richard,

As far as I'm aware there aren't many other options you could consider, if you want to have a long list of static records.

I'd typically use Static Entities when what they define is mostly immutable and useful to know and use at design time. The only reason I usually have to start with a regular Entity, bootstrap it and then converting it to a Static Entity is when conceptually I have a lookup table with lots of records (like your example of Countries, that you can see on the Location component). Since at the database level they are really the same thing, the main difference is only to represent the immutable nature of data (and I don't think there are any drawbacks, as you can convert both directions Entity<->Static Entity) and be able to use the record names in our code directly.

Also, static entities are pre-filled when deployed, unlike regular entities, where the bootstrap process relies on timers that run sometime after the application is deployed.

Hope this helps!

Solution

Jorge Martins wrote:

Hi Richard,

As far as I'm aware there aren't many other options you could consider, if you want to have a long list of static records.

I'd typically use Static Entities when what they define is mostly immutable and useful to know and use at design time. The only reason I usually have to start with a regular Entity, bootstrap it and then converting it to a Static Entity is when conceptually I have a lookup table with lots of records (like your example of Countries, that you can see on the Location component). Since at the database level they are really the same thing, the main difference is only to represent the immutable nature of data (and I don't think there are any drawbacks, as you can convert both directions Entity<->Static Entity) and be able to use the record names in our code directly.

Also, static entities are pre-filled when deployed, unlike regular entities, where the bootstrap process relies on timers that run sometime after the application is deployed.

Hope this helps!

Thanks Jorge, that seems to confirm my understanding.  I have not got as far in my learning as using components yet, where will I find out more about this ?  And when would you use a component like the Location one over what we have described above ?

Cheers, Richard.


Well... components are just modules or applications you can install in your environment and reference from your own modules. If you haven't yet created multiple modules and referenced them from each other, then I recommend you review the online training (or go through classroom training, if that's more up your alley): IIRC you're exposed to it since almost the first exercise, as applications developed during training rely on at least two separate modules, one a producer for Entities and Actions, the other the consumer module with the screens etc.

The Location component's team has already done the work for you, in the case of Countries and States... it's mostly a not reinventing the wheel... if the info they put there is enough for you, use them.