1

I'm working on a product information manager, and I have a content type of product which needs to reference stock and price levels for each supplier from a different database - these are stored as separate sqlite databases (one for each supplier) and managed outside of drupal.

I would like to reference the prices and stock levels without actually importing them all into the drupal database, instead pulling from the external database, but I'm a little confused how to structure this? One product can have many suppliers.

Do I need a separate entity to manage the pulling of the data (possibly one entity for each supplier) then somehow attach to the product node (manufacturer and part number would be used to search the supplier db), or, would it be considered a field, or a module with options set specifying the database location for each content type. Each product node shouldn't have to specify its list of suppliers.

The data would need to be shown when a node is displayed - I would like the data to be accessible from within views, but also searchable, e.g. display products where stock level < 3 for supplier xyz.

I'm thinking an entity wouldn't be correct as an input of manufacturer and part number would be needed before the data can be pulled?

1 Answer 1

1

The data would need to be shown when a node is displayed - I would like the data to be accessible from within views, but also searchable, e.g. display products where stock level < 3 for supplier xyz.

How can you say I want the data to be integrated into my website -- but not imported into Drupal. Your goal sounds like alot of work.

You could try something like Remote Entity. But honestly I would take some time to learn the Migrate module and use Rabbit Hole to insert the data as "hidden" data to drupal entities or content types in my site. Migrate is super powerful for this type of syncing of data (syncing being a topic I think you're glossing over).

EDIT

You could try to:

... all of these in my opinion would be harder to maintain in the long run, rather than a recurring interval of updates or syncing of data using Feeds, Migrate, and storing a copy of the data locally in a drupal friendly format (eg a content type or entity).

4
  • I've considered syncing data, and it isn't feasable considering the high quantity of products I would need to sync, spread over a number of suppliers, only for the data to change at any point - the data is external and used by external systems. Commented Nov 26, 2014 at 23:07
  • As an example, the Migrate module supports a hash value for imported data -- so on subsequent imports data is either created /updated or left untouched if no changes have occurred. just saying ...
    – tenken
    Commented Nov 26, 2014 at 23:08
  • The data would have to be continually sync'd 24/7. Why do this instead of just using the external database? Commented Nov 26, 2014 at 23:09
  • @user3791372 see my edit. good luck on your project.
    – tenken
    Commented Nov 26, 2014 at 23:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.