After milestone 5, new tenders arrive in the Kladde every night. A few weeks later there are hundreds, and a simple list no longer helps the office. It wants to know: What’s still open, what fits us, and what has to be submitted by the end of the month? The sixth milestone makes the tenders searchable, with filters in the address like the contacts from milestone 1 and with a detail page that leads to the notice at TED.

No new tools come in. You put together what you know from lesson 2.4.9 (queries with EF Core), 2.5.4 (showing data with static SSR) and milestone 1. What’s new is a question that comes up with every search: How does the rule for what “fits” stay in one place when it has to run once in memory and once in SQL?

Pull request Branch Brings Where in this lesson
1 feature/m6-tender-query the query in the core: CPV prefix, country, deadline, expired, page, the rule Matches “Pull request 1” and exercise 1
2 feature/m6-tender-search-sql the same rule as a query with EF Core, a test against SQL Server “Pull request 2”
3 feature/m6-tender-pages the list with filters and pages, the detail page with a link to TED “Pull request 3” and exercise 2

Where the Kladde stands

After milestone 5, the solutions have this:

  • The table Tenders has one row per notice (TenderRow in Kladde.Data): number, title, buyer, country, the CPV codes as a list, day of publication and deadline. The number has a unique index, the deadline an ordinary one.
  • The page /tenders shows the sentence about the last import (ImportRunLine) above a simple list.
  • The contact list from milestone 1 has search and pages through the address, with ContactQuery and Page<T> in the core.

If your files, classes or folders are named differently, keep your names and carry the steps over.