Root / Assembly / ARCCore / Class / PropertyStreamLine
|_Member||AllowedPropertyStreamLineKeyPartChars, AllowedPropertyStreamLineValuePartChars, DecodeStringFromPropertyStreamFormat, EncodeKeyPartStringToPropertyStreamFormat, EncodeValue, EncodeValuePartStringToPropertyStreamFormat, EncodeValues, ParseAndStoreFailSafe, StoreFailSafe, StoreFailure, System.String EncodeKeys(System.Collections.Generic.IEnumerable`1[ARCCore.IK]), System.String EncodeKeys(System.Collections.Generic.IEnumerable`1[System.String]), TryParseDirectToIP, TryParseDirectToProperty, TryStore|
|Description||Has two main functions:|
1) Encodes and decodes single lines in the PropertyStream.
See methods like EncodeKeyPartStringToPropertyStreamFormat, EncodeValuePartStringToPropertyStreamFormat and DecodeStringFromPropertyStreamFormat.
2) Stores single lines in the PropertyStream into a data-storage. See TryStore.
3) Parses a collection of PropertyStream lines into a single IP instanse.
See methods like TryParseDirectToIP.
4) Parses a single PropertyStream line into a single property.
See methods like TryParseDirectToProperty.
A line consists of a key-part, the separator ' = ' (space, equals sign, space) and a value part.
(the value part may be empty, see PValueEmpty).
Examples are (syntax only approximate as of May 2020):
'// This is a comment (lines starting with // are to be ignored in any processing
'dt/Customer/42 (create new Customer object, actually this line is not necessary)
'dt/Customer/42/Cid = User/43' // (See Cid)
'dt/Customer/42/FirstName = John'
'dt/Customer/42/PhoneNumber/+4790534333' (create new PhoneNumber)
'dt/Customer/42/PhoneNumber/+4790534333:Invalid = 2020-03-12 08:42:11' (Equivalent to 'delete', see -Invalid)
'dt/Order/1968/CustomerId = Customer/42'
'dt/OrderLine/2001/OrderId = Order/1968'
'dt/OrderLine/2001/ProductId = Product/2003'
'dt/OrderLine/2001/Quantity = 3'
'dt/Product/2003/Name = Widget3'
'dt/Product/2003/Colour = Red'
Note that timestamps are normally not needed because the property stream is sequentially organised, and timestamps are inserted automatically (see TimestampResolution).
See EncodeKeyPartStringToPropertyStreamFormat and EncodeValuePartStringToPropertyStreamFormat for how data is actually encoded (examples given above are only indicative).
Note that this class is static, that is, no instances if this class are ever created.
Instead simple strings are used for representing property stream lines for transmission and storage. This is considered to be more efficient (less processing required) and take up less memory (especially for CoreDB).
|LongDescription||FAQ: Is the property stream (and AgoRapide in general) strongly or weakly typed?|
That is up to you.
For getting started, and just in order to experiment with some various data, you can start weakly typed, or just use strings everywhere.
A standard storage like PRich and a generic ARAAPI built on top of that is not dependent on any pre-defined structure, it just accepts whatever is in the property stream.
In your C# code you can use multi-level indexing like this: 'DataStorage["Customer"]["42"]["FirstName"] = "John"' without bothering about types at all (or just send the corresponding PropertyStreamLine 'dt/Customer/42/FirstName = John' to TryParse).
As your project matures and you see which classes and properties are more important, you can create the corresponding 'entity' classes and their PropertyKeyEnum, and specify more exact types for the properties.
Taken into account concepts like LinkInsertionInDocumentation this will also constitute documenting your application.
Note that though you can choose the level of dynamic typing (as shown), static strong typing is always a bit weaker with PropertyAccess. See -AssertTypeIntegrity- and BoilerplateCodeProperties for attempts at alleviating this.
FAQ: How does the property stream format compare to the JSON format?
A JSON representation of some given data points could be seen as a 'compiled' variant of the same data points stored as property stream lines.
This is because the original property stream lines for a given JSON representation may be spread out (not being located close to each other).
Note however that if the actual property stream lines (for some given data points) reside consequently to each other in the data storage, then JSON would be a much more effective format for representation because it is much less verbose.
TODO: Insert examples here in order to clarify.
Some notes about compression:
Note how the format used is somewhat verbose but well suited for on-disk compression.
It is for instance inefficient (storage-wise) to repeat the same context line after line.
But on the other hand, the underlying OS can easily be instructed to compress the storage files instead (something it should be able to do quite efficiently, leaving the size-issue to mostly constitute a network bandwidth problem.
Note that some optimizations are performed anyway, see for instance Timestamp which describes how timestamps are not added to each and every property stream line but inserted as needed.
Generated 2020-10-13 11:11:05.179 UTC