Import same model from excel with unknown sheets number

[Svashtar]

Hi,

I have seen there is one similar question in closed status, but mine is for a bit different scenario.
I have a model with common attributes and additional dynamic attributes. Because for each category of the model there can be different sets of dynamic attributes i am exporting to excel with sheets for each category...

Now, i would also like to import records in same fashion. The problem is category names and number is unknown, so one file could have 5 sheets while the other a different number, but they are named by category.

Is there a way to iterate through all the sheets and make additional dynamic attribute definitions for import programaticaly?

Thanks

[gnapse]

No there is not. There is a way to define an importer to act on a specific sheet, which you can reference by name. What if you create an importer per each different of these categories? Each would define the columns expected for that category, and each will process the correct sheet if they are named appropriately.

I think you might even be able to create a hierarchy of importers: a base importer declaring the common columns expected no matter the category, and a sub-class per category, which would add the column declaration for the category-specific columns.

Would this work? Feel free to ask me further if I wasn't clear enough, or if what I say is not possible or I misunderstood the problem.

[Svashtar]

Thanks for the answer.
Unfortunately, categories and its attributes are not preset, meaning different number of categories with different names, etc. - which means that creating importers per category is not a solution.

I will probably need to look for another solution.

[gnapse]

I think you could maybe create importers dynamically in runtime. Ruby is dynamic and flexible enough to allow this. But maybe you'll need some meta programming.

As to wether give the ability to this library to do this, I'd say I would need to see a proposal at least, if not a pull request, which would be infinitely better. Also consider doing it in a way that does not get in the way of the normal more down-to-earth use of this library. I wouldn't want to get out of my way to modify for a very edge-case scenario, which seems to be your case. But I'd also like to see this library work for you too.