Search on train_schedule table

[EthanPERRUZZA]

Issue:

Endpoint: /search

Objective: Add a new object to the search functionality. Currently, we can search on items like rolling stock, etc. The new object to add is: train_schedule.

---

Things to Know

• Software for testing requests easily: Postman works well for testing.
• You can import from OpenAPI.
• There's an environment system where you can define variables for testing in local/dev environments easily.
• page and page-size: These are pagination options commonly found on websites, but they are already set up, so no need to worry about them.
• To test, I can make a request and check the network tab.
• Requests are done in Reverse Polish Notation.

---

Search AST Language

• like: for regex-style searches.
• =: for exact word matching.
• search: for smart search (case and accent insensitive).

---

TODOs

1. Understand what's in train_schedule: Refer to the SQL table and docs here: Train Schedule Documentation.

2. Check if the table is indexed: Ensure the train_schedule table is indexed (in SQL) by name, and create the index if necessary.

3. Define search parameters and results:

   • Declare which parameters we can search by.
   • Specify what the search will return.

---

Search Declaration

• The table name is train_schedule, no need for a join.
• Define the columns available for search (e.g., name).
• The structure underneath should represent the search results (ideally almost everything).

---

Other Considerations

• Make sure we can search by timetable_id as well.
• There's a timetable table and a train_schedule table, linked by timetable_id (primary key, which we don’t need to focus on, but it should be returned).
• There may be a test timetable, and we need to query the correct one.

---

Out of Scope

• No new tables.
• No migration needed.
• No need to handle fuzzy search.

---

Acceptance Criteria

• At a minimum, we should be able to search by name.

[celine-sncf]

@flomonster should we keep this issue open to add the date filtering? (or open another front issue ?)

[flomonster]

should we keep this issue open to add the date filtering? (or open another front issue ?)

No, we decided that the date filtering should be done by the frontend for now.