structureless loaders
Opened this issue · 1 comments
Warpten commented
Steps needed
- Separate loading logic from parsing logic
- Provide front-facing code that hides away all the type generation code and lets the user specify members using an
IEnumerable<some interface>
. - Either expand on the existing code, which means:
- Runtime type generation: slow, needs to be cached, no user control, not pretty
- ???
Possible issues:
- Input structurew will need to match file definitions 1:1 to not fail.
- Provide clear errors to the user if something is done wrong.
Surface layer
public interface IMember
{
tring Name { get; }
MemberType Type { get; } /* enumeration of int, etc */
int Cardinality { get; } /* cardinality, default to 1 */
// ?
}
Example of user code
using (var fileStreram = ...)
{
var storage = new Storage(fileStream, new DynamicStructure().field("ID", MemberType.Int32).field("Name", MemberType.String).build(), StorageOptions.Default);
// 0 is the record key (different from ID - it's still the user's task to create a dictionary)
Console.WriteLine("{0} - {1}", storage[0]["ID"].Integer, storage[0]["Name"].String);
var allNames = storage["Name"].Strings; // IEnumerable<(int, string)>
}
Warpten commented
In hindsight of current progress:
- Fluent API isn't the best but it'll stay for lack of better ideas.
- Really hard to efficiently deal with arrays.
- File parsing needs to be redesigned (again sigh)
- Header read
- Generate type metadata
- Prepare blocks linked list
- Parse blocks
- set up type mapping if needed
- parse records