merging JSP and some pre-existing code
has anyone had experience yet with using JSP on an existing project?
I only have about 2 weeks into a new project when I came across JSP and figured "if i'm gonna use it, the sooner the better"....but not exactly sure what path I should take . For example:
1) create a new project by cloning JSP as if it's a new project
2) name the PG database the same as in the existing project (that way, the data that I've already dropped in there plus key data like existing migrations is in there)
3) drag over code from the "old" app to the new
3a) how to handle migration files? After all I already had Devise and a few other things set up in the old project.
3b) any gotchas to think ahead about? go over any config files for settings I'd forgotten I'd set, etc.
3c) ?
Option 2 is to treat the new project as truly new, with a new DB, and new migrations as needed from various gems (Friendyld, using a UUID for a Company's id, that sort of stuff) and bring over only such code as might be needed from controllers, views, models on a case-by-base basis
thank you for your thoughts
I only have about 2 weeks into a new project when I came across JSP and figured "if i'm gonna use it, the sooner the better"....but not exactly sure what path I should take . For example:
1) create a new project by cloning JSP as if it's a new project
2) name the PG database the same as in the existing project (that way, the data that I've already dropped in there plus key data like existing migrations is in there)
3) drag over code from the "old" app to the new
3a) how to handle migration files? After all I already had Devise and a few other things set up in the old project.
3b) any gotchas to think ahead about? go over any config files for settings I'd forgotten I'd set, etc.
3c) ?
Option 2 is to treat the new project as truly new, with a new DB, and new migrations as needed from various gems (Friendyld, using a UUID for a Company's id, that sort of stuff) and bring over only such code as might be needed from controllers, views, models on a case-by-base basis
thank you for your thoughts
Over 2 cups of coffee and a croissant, this is my plan:
0) make sure "old" app is at its own repo's head and you've got a clean working branch; re-run test suite on old app
1) export existing data into a backup , either postgress dump or an export of individual tables via Postico to csv. Don't bother to export data that you can as easily re-generate once this whole mess is over (such as: the 2-3 example users I have in my 2 week old app that only I use). However you might find it more comforting to export all of it, even if you don't need it all later. If you want to keep the "old" app's database, then make sure the name of it in Postgres matches the name in database.yml. Personally I wanted to keep the "old" db and app name for the "new" app, so I had to rename the database in Postgress etc.
2) use a virgin JSP and db:migrate.
3) keep two VScode screens up at the same time and pick elements from my "old" app's migration files that I want to use in the new app. A lot of the original migrations (for example, for Devise) are redundant to port over. However if you have some customizations, for example, you introduce a "full_name" olumn to Devise's User, then bring that over.
4) do the above for al your migration files. If you're using git and you were up to date on your branch to start, delete lines from your "old" migration files as you do this step. when all you're old migration files are empty, then you are done. ;)
5) run db:migrate again and import data you exported back in
6) now bring over files from the old app : Model, Views, Controllers, Jobs, etc. Test suite. This should be an easier copy-paste for anything that JSP doesn't already use; and a little more complex for something JSP does use such as User, etc. where you'll do some copy-paste
7) re-run tests
8) discard any branch you used on the old app while you were doing the migration deletions in step 4 above
9) git commit on the new app
10) personally, I'd re-run tests again, but that's just cause i'm not an expert so I need the safety net
hope the above helps someone. I don't know if it's all correct but I figure it gets me closer to goal.
0) make sure "old" app is at its own repo's head and you've got a clean working branch; re-run test suite on old app
1) export existing data into a backup , either postgress dump or an export of individual tables via Postico to csv. Don't bother to export data that you can as easily re-generate once this whole mess is over (such as: the 2-3 example users I have in my 2 week old app that only I use). However you might find it more comforting to export all of it, even if you don't need it all later. If you want to keep the "old" app's database, then make sure the name of it in Postgres matches the name in database.yml. Personally I wanted to keep the "old" db and app name for the "new" app, so I had to rename the database in Postgress etc.
2) use a virgin JSP and db:migrate.
3) keep two VScode screens up at the same time and pick elements from my "old" app's migration files that I want to use in the new app. A lot of the original migrations (for example, for Devise) are redundant to port over. However if you have some customizations, for example, you introduce a "full_name" olumn to Devise's User, then bring that over.
4) do the above for al your migration files. If you're using git and you were up to date on your branch to start, delete lines from your "old" migration files as you do this step. when all you're old migration files are empty, then you are done. ;)
5) run db:migrate again and import data you exported back in
6) now bring over files from the old app : Model, Views, Controllers, Jobs, etc. Test suite. This should be an easier copy-paste for anything that JSP doesn't already use; and a little more complex for something JSP does use such as User, etc. where you'll do some copy-paste
7) re-run tests
8) discard any branch you used on the old app while you were doing the migration deletions in step 4 above
9) git commit on the new app
10) personally, I'd re-run tests again, but that's just cause i'm not an expert so I need the safety net
hope the above helps someone. I don't know if it's all correct but I figure it gets me closer to goal.
What I never figured out:
given that migration files have a time stamp on them, how to deal with future migrations that *I* create for my app and future migrations that JSP does for JSP that have intervening timestamps. I have no idea how the DB table that tracks migrations will know what to do with such migrations that haven't been run yet from a fetch-merge, some of which may pre-date and post-date my local migrations
I leave that up to
Chris Oliver
, who probably already knows the answer
given that migration files have a time stamp on them, how to deal with future migrations that *I* create for my app and future migrations that JSP does for JSP that have intervening timestamps. I have no idea how the DB table that tracks migrations will know what to do with such migrations that haven't been run yet from a fetch-merge, some of which may pre-date and post-date my local migrations
I leave that up to
Notifications
You’re not receiving notifications from this thread.