i am working on a project

i pulled the code, installed all the modules, then run migration, then run seed

then there was an error during seeding, so i unseed it, and then rerun seed

then when run software, suddenly the software got error

i investigated. and then found out what went wrong

the software relies on rows obtained from a certain sql table and rely on the auto-increment primary key for configuration

for eg, its like (just example)

theme_table

id | theme

0 | dark

1 | light

when you unseed it, and then re-seed it. the auto increment kicks in and then repopulated to increasing id

now become

theme_table

id | theme

2 | dark

3 | light

since the software cant find 1 and 2, and it is coded to find 1 and 2 only. it returns error.

i ask the others they dont have the problem because they have only seeded it once.

i am meeting up with the team on saturday. can i raise this as poor software design?

May be :
* Less consideration / auto or default configuration.
* Lack of error handling.
* Lazy to do complex settings.

* other reasons...





This post has been edited by flashang: Aug 18 2023, 12:31 PM

Just a buggy implementation. Just add a step before your seeding step, test, commit, send pull request and move on.

Should be faster and more productive for everyone.

This post has been edited by angch: Aug 18 2023, 12:49 PM

I'd attribute the OP's troubles to a buggy seed/unseed script instead of as a design problem. After all, it had one job: put the system in a known working state after a fresh install, and it failed!

Unless the "Developer Experience" is one of the project's goals, implementing anything more elaborate puts one squarely into "over-engineering" territory.

they can reduce bugs by using order by id limit 1,
show proper error 'cannot get setting from table x'

or set default value if no 'custom settings'.

it helps dev and ops teams to check where is the problem.





This post has been edited by flashang: Aug 19 2023, 10:09 AM

problem solved for all the tables that suffers from this
i just implemented an id in the seeding process to force a value we want on it

If its seeding for a local dev environment, then its not necessarily bad. As any errors that show up coulld indicate you did not do the set up properly.

Since you said config relies on the ID value, it also stands to reason you should be able to update the config?

It's a bug but personally I don't think it's a problem.

In terms of impact, it's negligible. It's not affecting production, staging, or even other developers.

That said, you did the right thing with the fix. So good job right there.