allow consuming data without a declared class

[jamesmanning]

This may well be more trouble than it's worth and/or out of scope for the project, but I have a set of spreadsheets I need to pull data from and unfortunately they're not homogeneous in their layout, although they are all in the category of having sheets with a header row and then the rest of the rows in the sheet are for data.

The consumer code that would be nice (but obviously not required, i can always just talk to the underlying gdata directly) would include:

1. having GetTable<dynamic>(sheetname) (or GetTableAsDynamic if it should be a separate method) that used the header row to determine property names (the IDatabaseClient or IDatabase could expose the public Func<string, string> PropertyNameGetter { get; set; } being used for mapping header names to property names in case the user wants to override the default).
2. having a GetDataTable that does similar, but instead of being properties in a dynamic POCO, just uses the normal System.Data.DataTable. Optionally, fetch all sheets in spreadsheet as a DataSet.

Similar to how some of the ODBC / Access / ACE / Excel stuff I've used in the past seems to do, it could/should look at the data in each column to figure out the "best" (strongest) type it can use (int, double, string). IIRC the number of rows it would scan to figure out the type for a given column defaulted to 20, but you could configure it as either 0 (all rows) or anything 1 or higher.

Again, this may be way outside the scope of GDataDB, or maybe even better done as a separate project, just wanted to file the issue in case it's something that might end up being a good fit for GDataDB's scope.

[Novack]

I found myself in a similar case some time ago. Resulted much easier to not use GDataDB at all.

In fact the google data api is not so complicated, and you will usually encapsulate the calls anyway.

[mausch]

So basically you do have a fixed and known number of columns, but you don't have the types, right? If so, have you tried making your properties strings or objects? And then you'd use your own reflection/dynamic/parsing/etc code to manipulate the values.

[jamesmanning]

@mausch at least for my situation, i was more hoping for something that I could just point at a spreadsheet (which, IMHO, already defines a "schema" through the header row) and suck that into a set of dynamic objects, all having the same set of properties, with property names as sanitized versions of the header row strings and property types determined by looking at the contents of the column.

Since it's not "in the box" with GDataDB, though, I'll probably just implement the fallback I had been thinking about - a separate LINQPad script (my existing GDataDB code is in a LINQPad script already) that I can point to a spreadsheet and it'll generate the classes (as source code) for each of the sheets in the spreadsheet - then I could just paste them into the consuming code and use those generated classes with GDataDB. :)

Thanks, @mausch !