SQL Fetcher and Parser

Feeds or an add-on module to Feeds would be the right place to do that. No plans to implement this atm.

Nobody working on this for now.

I needed to do this for a drupal 7 project and have it in my sandbox at: http://drupal.org/sandbox/johnbarclay/1255908. It may work now. It will definately work after I implement this in the project I'm using it on. It needs some polish and documentation before it goes anywhere also.

It has an SQL fetcher and SQL parser. The SQL fetcher is configured by:
(1) selecting a database from the global $databases array normally defined in settings.php
(2) entering some sql

This allows me to leverage the batch/cron, universal id, and processor classes functionality of feeds.

The use cases, including mine:
- querying external MSSQL server for taxonomy, entity, and user data.
- convoluted queries to the drupal db to generate edge data needs
- getting a feed going when you don't have time to set up a webservice

When its farther along, I would prefer it to be in the feeds project, but can publish it (or someone else) as a separate module.

Had some design questions on this:

1. This fetcher and processor simply return database fields which are mapped. I can't see much use case for the node storage of an importer using this fetcher/parser pair. Should I simply disable it through hook form alter or what's the best way to do this?

2. Since the parser is just turning a recordset array into an array ready for the processor, should this module implement a parser at all? Or is there a generic FeedsParser that could be used instead if the FeedsFetcherResult data was in the correct format?

3. Should I use the FeedsWebTestCase class to build the simpletests on, or is it designed for plugins within the feeds module itself?

I fixed a bug in this where null columns weren't processed correctly. The update is in the sandbox now.

sub

It looks like Feeds Database does something similar: http://drupal.org/project/feeds_db

I have no plans to pursue this patch and I think feeds_db is more promising since it has a home.

I'm the maintainer for feeds_db, and I agree it needs to be a separate module, for a number of reasons. I'm co-maintaining feeds too, so I'll be sure both walk side by side. If you're not unhappy with it, I'll close this issue. Feel free to re-open it or open issues on feeds_db, that would be greatly appreciated.