Results 1 to 3 of 3

Thread: Nested Tables - Child XTables

  1. #1
    Junior Member
    Join Date
    Feb 2012
    Posts
    15

    Default Nested Tables - Child XTables

    Is there some support for child collections. Storing an array or List is not ideal because the whole collection gets loaded and stored on every update. We need a away to just add to a collection. Or get a reference to the collection and update it.

    Eg,
    XTable<UInt32,bool> NestedCollection  = ParentTable[ndx];
    
    Should only return the XTable reference.

    If STSDB has this ability, then it would be very fast to update a "Value" collection.

    Is a locator the only identifier for an XTABLE? Is there a way to find it by an offset? Locator is not a supported type so we need an locator that can be stored in an XTable.

    If we had such a locator then the parentTable is XTable<Int64,#Indentifier for XTable#>

    UInt64 NestedCollectionOffset = ParentTable[ndx];
    XTable<UInt32,bool> NestedCollection = StorageEngine.Scheme.OpenXTable(NestedCollectionOffset);
    

  2. #2

    Default

    The Locator type is supported type - both as key and record. It is a database specific type, but you can use it in your own tables:
        XTable<TKey, Locator> table;
    
    or
        XTable<Locator, TRecord> table;
    
    Is a locator the only identifier for an XTABLE?
    Good question. If you look at the SystemRecord in the Scheme table, you will notice, that every XTable is actually identified by two things: the RawFile handle and the starting position in that file. Two ulong values.
        public class SchemeRecord
        {
            /// <summary>
            /// Container RawFile Handle
            /// </summary>
            public ulong Handle { get; set; }
            /// <summary>
            /// Position of XTable in RawFile
            /// </summary>
            public ulong Offset { get; set; }
            /// <summary>
            /// Type of the XTable(TKey, TRecord)
            /// </summary>
            public Type Type { get; set; }
    
            public SchemeRecord()
            {
            }
    
            public SchemeRecord(ulong handle, ulong offset, Type type)
            {
                Handle = handle;
                Offset = offset;
                Type = type;
            }
        }
    
    So, the answer is "no" - the locator is not the only identifier for a XTable. The locator type is just an identifier wrapper. And, in theory, you can build your own "scheme" system, based on some other identifier (int, string, double, custom etc.).

    The current Scheme is:
    locator -> (handle, offset)
    
    but you can create your own, based on other type.
    identifier -> (handle, offset)
    
    Then, instead of creating & opening XTables trough the official Scheme:
        public class Scheme : XTable<Locator, SchemeRecord>
        {
            public StorageEngine Engine { get; private set; }
    
            ...
    
            public void Register<TKey, TRecord>(Locator locator, XTable<TKey, TRecord> table)
            {
                this[locator] = new SchemeRecord(table.RawFile.Handle, table.Offset, table.GetType());
            }
    
            public XTable<TKey, TRecord> CreateXTable<TKey, TRecord>(Locator locator, RawFile rawFile)
            {
                XTable<TKey, TRecord> table = new XTable<TKey, TRecord>(rawFile, rawFile.Length);
                Register<TKey, TRecord>(locator, table);
    
                return table;
            }
    
            public XTable<TKey, TRecord> OpenXTable<TKey, TRecord>(Locator locator)
            {
                SchemeRecord record;
                if (!TryGet(locator, out record))
                    return null;
    
                if (record.Type != typeof(XTable<TKey, TRecord>))
                    throw new InvalidCastException("Incompatible types.");
    
                RawFile rawFile = Engine.FileSystem.OpenFile(record.Handle);
                return new XTable<TKey, TRecord>(rawFile, record.Offset);
            }
        }
    
    you can create & open XTables (only or additionally) trough your scheme:
        public class NewScheme : XTable<TIndentifier, SchemeRecord>
        {
            public StorageEngine Engine { get; private set; }
    
            ...
    
            public void Register<TKey, TRecord>(TIndentifier indentifier, XTable<TKey, TRecord> table)
            {
                this[indentifier] = new SchemeRecord(table.RawFile.Handle, table.Offset, table.GetType());
            }
    
            public XTable<TKey, TRecord> CreateXTable<TKey, TRecord>(TIndentifier indentifier, RawFile rawFile)
            {
                XTable<TKey, TRecord> table = new XTable<TKey, TRecord>(rawFile, rawFile.Length);
                Register<TKey, TRecord>(indentifier, table);
    
                return table;
            }
    
            public XTable<TKey, TRecord> OpenXTable<TKey, TRecord>(TIndentifier indentifier)
            {
                SchemeRecord record;
                if (!TryGet(indentifier, out record))
                    return null;
    
                if (record.Type != typeof(XTable<TKey, TRecord>))
                    throw new InvalidCastException("Incompatible types.");
    
                RawFile rawFile = Engine.FileSystem.OpenFile(record.Handle);
                return new XTable<TKey, TRecord>(rawFile, record.Offset);
            }
        }
    
    Of course, the NewScheme table must be first registered in the official Scheme and the TIndentifier type must be supported as key type.

  3. #3
    Junior Member
    Join Date
    Feb 2012
    Posts
    15

    Default

    Hmm..this would work if creating a new XTABLE wasn't so slow.

    Proper column family support is crucial to a NOSQL databases.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
2002 - 2014 STS Soft SC. All Rights reserved.
STSdb, Waterfall Tree and WTree are registered trademarks of STS Soft SC.