First, let me qualify my question by saying, I have not tried this module yet. I'm considering it for a D8 site, and the D8 port of this module is still over in Git. [And, apologies for tagging this as 7.x - there's not yet an option for 8.x.]

One of our requirements is that the client will need to be able to enter historical data. In that case, they will need to enter the value of the serial field instead of letting it auto-increment. Those values would be less than the current highest value in the table(s).

Is this possible with the Serial Field module? Is it simply a matter of either entering the number to override or leave it blank to let it auto-increment?

Comments

ExTexan created an issue.

wdseelig’s picture

wdseelig CreditAttribution: wdseelig commented

Did you ever get an answer to this?

I'm going to be trying to do this with feeds, perhaps as soon as tomorrow, and will post any results that I get.

ExTexan’s picture

ExTexan CreditAttribution: ExTexan commented

I wrote a quick module to read a node, update the serial id, and save the node. That worked. But now I'm doing the migration, via the D8 Migration module. It doesn't override the serial id in the same way as can be done with hook_node_insert/update. You may have a similar issue with feeds.

Our current plan is to have a post-migration process that runs after the migrations (done in drush) that will take the value that should be in the serial field (saved in a temporary field) and update it that way.

wdseelig’s picture

wdseelig CreditAttribution: wdseelig commented

As best I can tell, the behavior is as follows. Let's call the id field in the import file CSVID, and the id field in the database DBID.

In the feeds importer processor, check both the "Import New (entity)" and the "Update Existing (entity)" buttons.

If the feeds importer processor maps CSVID -> DBID, then the following will happen:

  • Database items whose DBID matches a CSVID item will be updated
  • Items in the import file whose CSVID does NOT match any item in the database will be added to the database with a DBID equal to the CSVID.
  • Items in the import file with a blank CSVID will be ignored.



In order to get new items into the database, it is necessary to remove the mapping from CSVID -> DBID. When you do this, you get the following behaviors:

  • Items with a blank CSVID are added to the database with new serial numbers
  • Items with a non-blank CSVID field are also added to the database with a new serial number. [In other words, the entry in the CSVID field is simply ignored.]



It would obviously be more convenient if the first set of behaviors could be changed so that entries with blank CSVIDs would just be added to the database. I'm going to look into that, and will post any findings.

wdseelig’s picture

wdseelig CreditAttribution: wdseelig commented

Here are the results of another experiment.

With the CSVID mapped to the DBID, I imported a single item with a CSVID slightly larger than the largest DBID. As expected, I ended up with what looked like a "gap" in my database ID serial numbers.

Then, I removed the mapping of CSVID -> DBID, and imported a new group of entities. To my surprise, the first DBID for the new group was one more than the entity ID of the entity I had added in the first step.

In other words, it looks like in the first step SQL's auto increment got set to the CSVID value of that imported entity.

ExTexan’s picture

ExTexan CreditAttribution: ExTexan commented

Great research, @wdseelig. That's good info.

Unfortunately, this project appears to have been abandoned - no updates to the D8 version since Dec 2016, and the D8 version hasn't even been moved to D.org; - so it seems unlikely that your wish will be granted. :(

wdseelig’s picture

wdseelig CreditAttribution: wdseelig commented

Thanks, @exTexan. Maybe I'll have to figure out how to make the change myself ;-). I've already started poking around in the code, but don't have time now to figure it all out. If I ever do get something together, I'll post the results.