search

stmichael / data-import

sequel based dsl to migrate data from a legacy database to a new home.
MIT License
42 stars 9 forks source link

group block #39

Open stmichael opened 12 years ago

stmichael commented 12 years ago

It would be nice to have a simple construct to group import blocks like:

group 'employees' do
  dependencies 'manager', 'software developers', 'testers'
end

In my use case I have to import several tables into one table which we call 'employees' like above. For each table in the source database I need an import block. So I have import blocks called 'manager', 'software developer' and 'testers'.

If I had an import block 'salary' that has a dependency on employees and not necessarily on any of the specific employee types, I would have to add each dependency to 'salary'. It would be much nicer to group the employee types to a block called 'employees' and then add this dependency to 'salary'.

@senny what do you think about this?

senny commented 12 years ago

I see the usecase but I'm not sure if it deserves it's own construct. For what it's worth you could achieve the same goal by creating a script block with an empty body. Sure this feels a little like a hack but as long as it's only for referencing a list of dependencies with a single name I think it's fine.

stmichael commented 12 years ago

I thought of that too but I find it kind of misleading to use script or import.

senny commented 12 years ago

@stmichael I think it is, but if the DSL is flexible enough to adjust to "special" situations even if it is a bit hacky i think we are on a good way. There are always usecases that we can't write specific code for. I think this one is a corner case and if we can handle it with the current features it's good enough. Every feature we add, also adds complexity.

@stmichael do you think this is not an edge case?