I have to import some csv files into the database. Each file had a
corresponding model and table in the system.
So I was thinking that there will be some common methods for all the
importers (log, spent_time_in_miliseconds, run, ...) and some non common
methods (convert_line_to_parameters, ...). Some common methods will end up
calling particular methods (i.e. run will call convert_line_to_parameters
for each line in the csv file).
I'm new to Ruby so the first idea that I got in mind was using one abstract
class and the create one class for each model that has to be imported.
Then I realize that didn't look like a Ruby way to solve this problem. My
second thought was to create a module with all the common methods and
include that module in the different importers, but not sure its the best
way either.
It will be great to get some ideas from people with more experience to get
this done in the best way.
Thanks in advance.
Piter Fcbk wrote in post #1014749:
I have to import some csv files into the database. Each file had a
corresponding model and table in the system.
So I was thinking that there will be some common methods for all the
importers (log, spent_time_in_miliseconds, run, ...) and some non common
methods (convert_line_to_parameters, ...). Some common methods will end
up
calling particular methods (i.e. run will call
convert_line_to_parameters
for each line in the csv file).
I'm new to Ruby so the first idea that I got in mind was using one
abstract
class and the create one class for each model that has to be imported.
Then I realize that didn't look like a Ruby way to solve this problem.
Why that?
My
second thought was to create a module with all the common methods and
include that module in the different importers, but not sure its the
best way either.
I think both approaches are perfectly legal and OK.
It looks as if the only differing behavior might be to translate a CSV
record to fields for DB insertion. So maybe you can get away with a
single class which takes a block on construction which is later called
to convert each record. You can even read the arity of the block to
determine how many placeholders your prepared insert statement needs (if
you use some DB API with SQL directly).
Kind regards
robert
···
--
Posted via http://www.ruby-forum.com/\.
My impression after reading some blogs, articles and others on the web is
that Ruby programmers doesn't use to much abstractions since the language
provides other methods to this kind of issues (modules for examples). It
also pointed out to me, at least in the articles or answers I had read that
experience Ruby programmers usually disprove the use of abstract classes (of
course, always giving reasons and an alternative solution).
The idea of giving a block as a parameter is nice. There are a couple of
other functions but nothing I can't take the same approach.
The main reasons I wouldn't take that approach right now are that having one
class for each CSV/Model seem easier to test and more clear (since there are
3 methods particular to each CSV file).
Thanks for your answer.
···
On Thu, Aug 4, 2011 at 10:31 AM, Robert Klemme <shortcutter@googlemail.com>wrote:
Piter Fcbk wrote in post #1014749:
> I have to import some csv files into the database. Each file had a
> corresponding model and table in the system.
> So I was thinking that there will be some common methods for all the
> importers (log, spent_time_in_miliseconds, run, ...) and some non common
> methods (convert_line_to_parameters, ...). Some common methods will end
> up
> calling particular methods (i.e. run will call
> convert_line_to_parameters
> for each line in the csv file).
>
> I'm new to Ruby so the first idea that I got in mind was using one
> abstract
> class and the create one class for each model that has to be imported.
> Then I realize that didn't look like a Ruby way to solve this problem.
Why that?
> My
> second thought was to create a module with all the common methods and
> include that module in the different importers, but not sure its the
> best way either.
I think both approaches are perfectly legal and OK.
It looks as if the only differing behavior might be to translate a CSV
record to fields for DB insertion. So maybe you can get away with a
single class which takes a block on construction which is later called
to convert each record. You can even read the arity of the block to
determine how many placeholders your prepared insert statement needs (if
you use some DB API with SQL directly).
Kind regards
robert
--
Posted via http://www.ruby-forum.com/\.
Yep! Abstract classes don't exactly exist in Ruby; there's no way to
do them exactly. A combination of mixins, duck typing, and delegation
is usually used over more heavyweight means of achieving polymorphism.