Activities of "leonkosak"

DeviceTypes in our case is defined from us and users cannot add/change/delete these entities in DeviceTypes SQL table (let's say max 100 device types). The number of DeviceTypes is negligible compared to how many instances one DeviceType could have (easily 100k+).

The next specific thing for DeviceTypes is also number of Devices (based on specific DeviceType). For instance, DeviceType1 has basically always much fewer devices because of the "nature" of this DeviceType. For instance, one tenant could not have a single device of DeviceType1, but have many of DeviceType3.

public class DeviceType : AggregatedRoot<int> {
    ...
    public ICollection<object> SomeDataList { get; set; }  //tipically 3-7 for all devicy types, not more
    public ICollection<Device> Devices { get; set; }
}

public class Device : AggregatedRoot<long> {
    ...
    public ICollection<DeviceSatusHistory> DeviceSatusHistory { get; set; }
}

public class DeviceSatusHistory : Entity<long> {
    ...
}

(DT = DeviceType)

Tenant      No. of devices of DT1   No. of devices of DT2   No. of devices of DT3
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
T1              36724                                 1254                                0
T2              146734                               800                                  22
T3              33535                                 135                                  55

Each Device has its own history. Some devices (based on specific DT are sending data, for instance, every 15 minutes, other devices (based on other DT) are sending for instance once per day. So the number of records in ICollection<DeviceSatusHistory> heavily depends on the DeviceType of a specific device. Of course, history table would be shrunk (old records) periodically, but the number of items in ICollection<DeviceSatusHistory> is expected to be huge anyway (the device has to have some history for the purposes of analysis and predictions).

Yes, this is my scenario. So "multiplicationg" the same code list across all tenant databases is technically good solution? :) (This also means that such code list in host database is at least duplicated - for host and for Default tenant. If more tenants is in host database, then "multiplication factor" for such code list is even higher.)

{{RequestLog["assetID"] }} maybe?

I am sure, that guys will upgrade. :) But look abp.io for your new projects. ;)

If connection string in appsettings.json would be encrypted for host database, how can system admin encrypt changed connection string and replace old one? For tenant it's simple, because C# logic makes encryption and decryption logic.

Let's say that we have the following co-related entities.

DeviceType Device DeviceStatusHistory

Each DeviceType has 0 or more devices (defined with serial numbers). Each device has 0 or more history (status history).

public class DeviceType : AggregatedRoot<int> {
    ...
    public ICollection<Device> { get; set; }
}

public class Device : AggregatedRoot<long> {
    ...
    public ICollection<DeviceSatusHistory> { get; set; }
}

public class DeviceSatusHistory : Entity<long> {
    ...
}

The main point is that DeviceType is "absolute root", but particular device is also "strong independent entity".

Is semantically correct that Device is also AggregatedRoot or it should be Entity<long>?

Thank you for suggestions.

For instance that one code list is common on application level. Tenant users cannot even change/add/delete values of this code list. Our policy is also that each tenant has to have separated database (and not inside host database). Such code list (SQL table) has IMAYHaveTenant in C# model.

Is something wrong, that Migrator creates code list values in each tenant database, because we want to limit number of SQL queries to host database. This is more important in public cloud environment (Azure,...) so that the costs of these queries are directly "forwarded" to tenant's database.

Can someone confirm that described concept is good or it's better to have such code lists just in host database anyway?

Thank you.

Based on all conversations on GitHub when mixing async and sync code, I would like to know if calling DataSourceLoader.Load in Task is REALLY safe (no thread starvation or other runtime problems possible?

public async Task<object> Get(DataSourceLoadOptions loadOptions)
{  
           object result = await Task.Run(() => DataSourceLoader.Load(SampleData.Orders, loadOptions));  
           return result;  
}

https://www.devexpress.com/Support/Center/Question/Details/T621512/how-to-use-datasourceloader-in-an-async-controller-action

Thank you for explanations.

My response is for Volosoft (in consideration for better background jobs). :)

Having jobs in tenant's database would also have better performance impact on database. If there are a lot of tenants in system and background jobs in each tenants are frequent, thare could be a bottleneck on host database. Consider also this aspect.