Generated classes doesn't have all the properties of the table schema

[hilario-cunha]

Because the code is only reading the first row of a table, the schema is incompleted. So to have the full schema is necessary to read all the values of the table.

In the SchemaBuilder class the GetModel method has the following statement, that can show what i'm saying.

// Read the first entity to determine the table's schema
var firstRow = dataContext.CreateQuery(table.Name).Take(1).FirstOrDefault();

[madd0]

I had noticed this before, but hadn't had the time to reproduce it. Have you noticed this on local storage, cloud storage or both? As I said, I haven't tried to reproduce the bug, but I suspect it may be due to yet another limitation of local storage ;)

[hilario-cunha]

This happens in both storages. To reproduce the issue you have to insert two rows with different columns.

[hilario-cunha]

I did another test and appears that in the local storage is working fine but in the cloud storage is failing.

The behavior is different between the two storages.

When you get the properties from the cloud storage the system sends only the properties that exist in that row.

In the local storage appears that is sending all the properties created in any row.

[jamesmiles]

I'm also having this problem.

My application uses a schema like this;

public class ParadoxProcessing : TableServiceEntity
{
    public string UploadedFilename { get; set; }
    public DateTime? Uploaded { get; set; }
    public string DatabaseName { get; set; }
    public string ParaProcessorVersion { get; set; }
    public DateTime? ProcessingStartedTime { get; set; }
    public DateTime? ProcessingFinishedTime { get; set; }
    public string Results { get; set; }
    public string LogFileName { get; set; }
    public string SqlAzureConnectionString { get; set; }
    public string InstanceName { get; set; }

    // Required
    public ParadoxProcessing()
    {
    }

    public ParadoxProcessing(string storeId)
    {
        PartitionKey = storeId;
        RowKey = Guid.NewGuid().ToString().ToLower();
    }
}

But in LINQPad I see...

select new
{
p.DatabaseName,
p.LogFileName,
p.ParaProcessorVersion,
p.PartitionKey,
p.ProcessingStartedTime,
p.Results,
p.RowKey,
p.Timestamp,
p.Uploaded,
p.UploadedFilename,
}

I think it is probably be columns have been added to the table rows at some stage. Maybe the driver is just looking at a subset of the rows to come up with the schema?

[barsh]

Same problem. Has anyone found a solution yet?

[nlewis-monscierge]

I'm having this problem too, and it is worse than indicated. It appears that if a value is null in the first row, that column will also not be generated, because it is not returned in the query.

[madd0]

Hello everyone,

First of all, sorry for the radio silence. I'm back.

Second, the issue is due to the assumption that the plugin makes that a table will have a predefined schema. This is not required by Azure, of course, but it was the only way to pre-populate tables and their rows in the plugin.

Evidently, quite a few people would like to use the plugin to access tables with "mixed" schemas. I have a few ideas I wanted to test during the weekend, but I cannot guarantee any of them will be satisfactory to everyone. I'll let you know how this moves forward.

Regards,

Mauricio

[madd0]

So, over the weekend I settled on adding a new field in the plugin's configuration window. It will allow users to provide the number of rows that should be sampled to determine the schema of a table.

Since I have a day job too, it'll take me a day or two to properly write and test. I'll keep you updated.

[madd0]

I finally pushed the new version. There's not absolute solution to this problem, but defining a number of rows to scan should be enough for most people.
Let me know how it goes.