Root / Assembly / ARCCore / Class / PRich
|Description||Fully flexible storage. Can store anything. Typical inherited for entity representations like 'Customer' or 'Order'.|
PRich = rich property. Rich in the sense that it can store a wide amount of information.
Can also function as a 'root' storage for all data.
Inherently not thread-safe due to using Dictionary and not ConcurrentDictionary as storage.
See tips about locking in documentation for OutsideLocalReceiver and some practical code in ARCDoc
See PConcurrent for a (somewhat more) thread-safe alternative.
See PExact<EnumType> for a more memory efficient alternative.
A more expensive (memory-wise) 'property'-object to use compared to PValue<T>.
Probably suitable when you want full flexibility about which metadata to store (see PP) and / or want to store child properties.
Most probably the one to use for 'ordinary' entities like 'Customer', 'Product' and so on, whereas PValue<T> is often used for single values for these instances (like 'FirstName', 'Price' and so on).
An instance of this class can also be used as the single total in-memory data storage in your application.
A typical representation would then consist of dictionaries inside dictionaries, with IK-keys and either PRich-values or specific IP-subclass instances (like 'Customer') values inside those again.
Such a usage would be very typical for a Client but also possible for ArmDB (enabling it to answer AdHocQuery over an TCP/IP connection.
With such a usage the instance of this class would typically populated by calling -ParseAndStore-.
|Interfaces||ARCCore.IP; -System.Collections.Generic.IEnumerable`1[ARCCore.IKIP]-; -System.Collections.IEnumerable-|
|LongDescription||Note that in a 'StandardAgoRapideCode-only application' IKString (or IKType but generated from FromString) will be used more as key, and PRich more used as values (instead of more specific IP-subclass instances (like 'Customer')), because the actual types and property keys are not known.|
Although their names may be known because they can be announced over the property stream, the definition for those types are unknown (the types are not present in the assemblies constituting the application).
This means that for instance an ArmDB application may not be able to validate all data, or answer the most complex queries (because it lacks the type information and has to operate more on strings).
TODO: Implement storing of this collection to disk at regular intervals.
TOOD: Background: If data are received from StreamProcessor through OutsideLocalReceiver
TOOD: (and read by StreamProcessor at application startup), then un-needed historical data will accumulate
TODO: (for instance if this object stores only the last temperature, but all temperatures are stored to disk).
TODO: Solution: Replace disk storage at regular intervals by serializing this object's data to disk with ToPropertyStream.
Generated 2020-10-13 11:11:05.030 UTC