Consider abstract Import and ImportJob classes and/or interfaces

[patrickmj]

With four modules now doing imports from different types of sources (Zotero, DSpace, Fedora, Omeka 2), I think we're ready to make decisions about abstracting functionality and practices

Here's info that I'm recording so far in all but Zotero Import that seems useful. Mostly these get stored on a subclass of Entity, but in the Job classes there are also properties just to tally the data up.

Import entities:

• id
• job_id
• comment // workflow information about the import (owner is also useful, and traced through job_id)
• added_count // number of items added from the import
• updated_count // number of items updated from the import
• version // only in ZoteroImport, but seems likely to be useful where it can be determined (DSpace, e.g., isn't good at making this clear)

added_count and updated_count clearly depend on another mechanism for keeping track. So far in my stuff, that's been in separate entities for each imported item and its relationship to the external content. That's a bit dependent on the data that the external system uses and reports.

Examples of the classes that might be abstracted this way are all the {module}/src//Job/Import.php job classes and all the {module}/src/Entity/{module}Import.php entity classes.

[zerocrates]

It seems to me that the best way to try this out is to try making a single module that hosts the various import options. It seems like it should be possible for many or most to differ only in the actual "guts" of the import. You could end up having only generic Job(s) and just an interface and some concrete implementations that job uses to handle the importing from the various services.

[patrickmj]

thanks. I'll poke around a little to see more of what that might entail and look like

[patrickmj]

what's your sense of whether this would make it harder or easier for people to build their own importers?

[zerocrates]

At worst, no change