Add new fields for Tail Number and Airline

[moshobo]

Closes #8

Add the following additional fields for flights:

• tail_number: String field for the tail number of the aircraft (ex: N896FD)
• airline: The 3-letter ICAO code of the airline operating the flight (ex: BAW)

I believe both of these fields will add a great additional dimension to flights, and the airline one in particular has already been requested as issue #8. I am also working on a PR for #51, which would greatly benefit from having a separate airline field, since that is data that was already stored.

Additionally, I started to enforce more that the airline code should be in ICAO format. Hopefully later on, this value can be used to display a more readable version of the airline (ex: Delta Airlines). It seems that the ICAO format was already preferred for airports, so I stuck to that.

Another minor change was to start enforcing that users must input the flight_number as a number going forward instead of a string.

Screenshots

All Flights

Add New Flight

Flight Details

[pbogre]

Hey @moshobo, thanks a lot for taking the initiative to open this PR! I appreciate the contribution.

I agree with the changes you have made, I just have a few remarks about implementation details.

1. Are airline codes manually inserted by the user (aka can be any string), or do they pull from an airline database? When I planned on implementing an airline column, I thought it would be a good idea to get a database of airlines and adapt it to Jetlog (very similar to how airports db is handled, and the airports db handler also has a airline db). Here is an example database, though I'm not sure how up-to-date it is. I would definitely like for the airline column to be similar to how airports are handled, i.e. pulling from a database.
2. I like the idea of the tail_number column. I am however not sure it should be present in the All Flights table, as my vision for that page is to contain only surface-level information about the flights, and details can be viewed my clicking on the flight. I suppose the importance of this column is up to discussion. I do think that the airline column can fit in the All Flights table. This column is fine without a linked database.
3. I am not sure about converting the flight_number column to type number, because the flight numbers I have been using do include letters, for example FR3461, which indicates it's ran by RyanAir with number 3461. Edit: I see now that this change works together with the addition of the airline code. With this knowledge, I would say that the change to number is fine (though it needs to be done in a way that supports backward compatibility, something I've improved upon in the PR for user auth), but that the flight number can be left out from the All Flights table, and the airline column should display the name of the airline rather than its code (made possible if airlines are linked to a database).

Again, thanks a lot for your contributions!

[moshobo]

Thanks for taking a look, @pbogre. Here are my thoughts to your response:

1. Yes, I agree that it makes more sense to pull from a database. I'll take a look at the one you linked, but on first glance it seems to be 5+ years old. Perhaps it is a good start and can be updated later? I'll add a commit that tries to use the database rather than allowing users to manually add a code. Or perhaps there should still be a manual override?
2. Yes, I can see your point here. I'm not sure every user will want to record tail numbers, so perhaps it should just be stored in the database and only shown on the Single Flight page. If there is enough interest in the future, it would be easy to add it to the All Flights table (or even make it a configuration setting)
3. it needs to be done in a way that supports backward compatibility -- I agree. For now I just made this change on the frontend (client), so that any new entries must comply. But the number is actually still stored as a string on the backend. Perhaps you could test it out and let me know?
   
   I guess it would be possible to create a somewhat complex migration that does the following (ex: FR3461):
   1. Find values in the flight_number that aren't integers (ex: [F, R])
   2. Combine those values into a string (ex: FR)
   3. Attempt to find the corresponding IATA or ICAO code for that string
      I'm not sure how you feel about this though, perhaps it is best to just assume flight_number will become a number over time?

I'll make changes to this PR in the coming days to update the following:

• Add an airlines database and use that information to populate the flights table
• Remove tail_number from the All Flights table
• Display airline name on All Flights (if a database can be found)

[pbogre]

For the airline database, make sure you follow steps similar to how the airports database was adapted(docs) and used in the backend (database.py). Currently i'm thinking the only required columns would be iata,icao, and name, but if the database provides other useful information we may keep that.

Since that database is quite old, feel free to look for another one that is more recent. I tried looking but didn't find much. When you get to a point where it has been adapted properly for jetlog, make sure you document the exact commands used in the process so that it can be easily updated in the future. If you stick to SQLite cli for this process, you can simply paste your history from .sqlitehistory, and cleanup redundant commands.

This change would also require another router, pretty much a clone of the airport one, at /api/airlines, as well as a React component similar to that of the airports. For this last change, I think the current airport input component can be abstracted to a generic SearchInput, which lets you specify which table to interact with.

After further thought about changing the type of flight number, I actually think it is best if we keep it as a string. Not only would the change require a decent amount of added code complexity, because of having to deal with backward compatibility (imagine what issues would arise if someone misspelled their flight number, for instance), but it would have little to no gain at this point. This is because we don't actually do any statistics with the flight number alone, so we might as well let people choose if they want to use it as a string or a number.

It could be changed in the future if we choose to do some statistics with the flight number, but for now I would say to keep it as a string on frontend & backend.

Thanks again for working on this :)

[moshobo]

@pbogre I've been looking around for databases of airline information, but all of them seem to be very outdated. I did manage to get an up-to-date CSV file that I made myself, but I'm not sure what you think of that. I could commit the .csv file to this project, then in the future if another source becomes available, it can be replaced?

[pbogre]

May I ask where you got the airline information from? As for the csv file, it would be nice if you could convert it to an sqlite database (it's quite simple, just a couple of commands), and then commit that to this PR so that i can review it.

Regarding some database, I was able to find this database of airlines (stored in javascript, which would have to be changed to an sqlite db) from a similar project. If your custom csv has less airlines than the ones found here, you could add them or use this file directly.