Results 1 to 3 of 3

Thread: XTable refuses to store null Child Class objects. Full objects make DB slow.

  1. #1
    Junior Member
    Join Date
    Apr 2011
    Posts
    28

    Default XTable refuses to store null Child Class objects. Full objects make DB slow.

    Hi! I have a question here.

    What if when after inserting at least 30000 full fledged records in a single class type. And this class type also contains optional child class objects which may or may not be filled, are rare to be filled, but as much as I define variable properties in the primary class which is stored into the db, as much it becomes slower and slower. I am having at least 4-5 different features in one single class which acts as a primary storage object. Thus if there are many variables with values, especially many child class objects which define the features, the fetching of records becomes a lot slower. I tried to define a class object with nothing value:

    
    Public Class StorageClass
    
    Public Property Obj1 as ChildClass1 = nothing
    Public Property Obj2 as ChildClass2 = nothing
    
    End Class
    
    Now the problem is that there is no way the Database XTable is going to store the primary class which contains the variable objects of child classes having null value. This is odd, I guess a bug unfixed. The rule is that even a null object should be stored. The reason is to null those objects which are of no use to us, and if they are not null, then they take up space hence this slows up the Database activity very much. Please take this odd bug be fixed. Even null objects have to be stored so that their values remain null too in the db. This might make DB activities faster than before. If you have any solution please tell. Thanks
    Last edited by aroratushar; 09.10.2011 at 20:11.

  2. #2
    Junior Member
    Join Date
    Jul 2011
    Posts
    20

    Default

    One way that would work for sure is if you implement a custom persistence class. It isn't a bug, as far as I can tell. It's just a feature that hasn't been on the list of features to be implemented. When you serialize arbitrary things to the disk, you have to have a common format for doing so. You could serialize a flag called 'has object' and write a boolean out, and if it is true, read the struct size of the child object, if not, skip it.

    Currently, when it auto-generates the serializer using reflection, it has to rely on the field structure of the object to create a serialization routine (how many bytes to read/write at a time, and what to put them in when it's done.) A null value doesn't conform to the field structure, so you'd have to figure out some other way to know, for example, how many bytes to read instead of the size of the structure itself... so it would be an exception to the pattern.

    That's not to say that it couldn't be done if the system were designed to accommodate it, however it's not something that I'd consider a bug. And it's a non-trivial feature. All this being said, I'm just a third party observer. I'm not the author of the software, nor in any way affiliated with them.

  3. #3
    Junior Member
    Join Date
    Apr 2011
    Posts
    28

    Default RE

    A Child Class's Schema could be stored with the primary storage class schema as a medium when we create a Class specific XTable. Then even if we null the value of the child class and the value is nulled even in the db Row, then it might make DB operations a lot faster for fetching and updating when the Storage Class is filled with more than 20 properties having values, and even child class objects that may or may not be null, optional. If we put tens of properties in the primary class, and even child class objects as properties to store, it would make db slower even at 10,000 rows fetching from db. Then in case of > 30,000 records it takes a while to fetch the records into memory from XTable. Null values are the best medium to create STSDB a lot faster because there may or may not be data in the null child class values, optional. I figured this out in practical testing and programing.

    Also, I figured out that storing Image Data Type objects directly, if the image object has an image of more than 1 MB, or a large photograph, if would take a lot of memory and time to load such class objects having images, a lot like 10,000 or more. Image could be an automatic Row based Blob/Blobstream? That only comes up when we manipulate the specific row and the object itself. Everything should be perfect, on the spot, and precisely flashing. Having non null large objects with huge megabytes of data, when we search through LINQ also, it is too much slow if we have thousands of rows in an XTable.
    Last edited by aroratushar; 12.10.2011 at 19:53.

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.