Dit is een beetje lang antwoord, dus ik heb het in secties verdeeld. Sluit je aan!
Mijn theorie
Mijn gok is dat uw ontwikkelingsdatabase doet bevatten de lessons_id_seq volgorde, en dat de definitie van flightlessons.id is ingesteld om ervan af te hangen (d.w.z. precies wat Rails in uw schemabestand plaatst).
Hoe en waarom? Je hebt waarschijnlijk de lessons hernoemd tabel naar flightlessons op een bepaald moment in het verleden, maar die hernoemen veranderde niets aan de volgorde waarvan de tabel afhankelijk was -- en sinds schema.rb doet niet reeksen opnemen, de lessons_id_seq sequentie wordt niet gekopieerd naar uw testdatabase en dus krijgt u deze fout.
Voer rails db uit om mijn theorie te verifiëren en probeer de volgende commando's:
\d lessons_id_seq
Dit zou de definitie van die reeks moeten teruggeven. Probeer dan:
\d flightlessons
En kijk naar de definitie van de id kolom. Ik verwacht dat het DEFAULT nextval('lessons_id_seq') . bevat .
Oplossingen
De eenvoudigste manier om dit op te lossen is door over te schakelen naar het gebruik van structure.sql in plaats van schema.rb (zie de documenten
). Hiermee wordt de exacte status van uw database overgenomen en wordt interferentie of interpretatie door Rails, de oorzaak van uw huidige probleem, voorkomen. Ik raad altijd structure.sql aan voor productiesystemen.
U kunt echter ook naar uw ontwikkelingsdatabase gaan en de sequentienaam wijzigen:
ALTER SEQUENCE lessons_id_seq RENAME TO flightlessons_id_seq;
ALTER TABLE flightlessons ALTER COLUMN id SET DEFAULT nextval('flightlessons_id_seq');
Dit zou een verschrikkelijk idee zijn op een productiesysteem, maar als uw probleem alleen lokaal is, zou het uw huidige databasestatus moeten corrigeren met uw schema.rb en zo uw huidige probleem aan te pakken. Misschien wilt u dat coderen in een migratie, als u wilt rails db:drop db:create db:migrate om aan een nieuwe app te werken.
Waarom nu?
Het gedrag waarbij Rails de default . weggooit waarde voor de primaire sleutel van uw tabel kan heel goed nieuw zijn in Rails 5. Voorheen vertrouwde Rails er misschien gewoon op dat uw ID-kolom een normale standaard had en negeerde het elke waarde die het daadwerkelijk zag. Maar ik heb geen onderzoek gedaan om te zien of dat waar is of niet.