Skip to content

Dynamic routing with _.sql #941

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 5 commits into from

Conversation

andrewsinnovations
Copy link
Contributor

This update allow you to create a _.sql file that will catch all routing paths in its folder and all subpaths, while still respecting the 404.sql process already in place.

For example, if your folder structure is such:

/
/models
/models/_.sql
/models/example/404.sql

and if you have this code in the /models/_.sql:

select sqlpage.path();
select sqlpage.variables();

and you have this code in /models/example/404.sql:

select 'Sorry, this page was not found';

In your browser, you can access any of these URLs with this result:

  1. / - this will render the default "It Works" page because there is no /index.sql
  2. /test - This will render the default 404 page built into sqlpage because there is no /404.sql
  3. /models/example/test - This will render "Sorry, this page was not found" because of /models/example/404.sql
  4. /models/mymodel?id=3 - This will render a page with /models/mymodel as the path, and {id: 3} as variables. It was caught by /models/_.sql
  5. /models/mymodel/submodel/test - This will render a page with /models/mymodel/submodel/test as the path, and {} as variables. It was caught by /models/_.sql
  6. /models/mymodel/anything/anything_more/yet_even_more/still_going?id=5&val=2 - This will render a page with /models/mymodel/anything/anything_more/yet_even_more/still_going as the path, and {id: 5, val: 2} as variables because it was caught by /models/_.sql

This allows for some simple dynamic routing.

This update allow you to create a _.sql file that will catch all routing paths in its folder.
Clippy returned errors for routing, and also an unrelated block of code with a redundant else block.
@andrewsinnovations
Copy link
Contributor Author

andrewsinnovations commented Jun 19, 2025

This functionality could possible be achieved with the existing 404.sql functionality. However that method indicates a "file not found" intended use, rather than allowing for dynamic routes. If a file named _.sql is used by convention for a dynamic catch-all, its purpose is more obvious.

@lovasoa
Copy link
Collaborator

lovasoa commented Jun 19, 2025

Hi !

Could you walk me through ? The goal is to avoid having to name catch-all files 404.sql, and allow naming them _.sql instead ? If this is only this, then maybe we should instead work on improving the documentation and adding examples, in order to make it easier for people to discover the existing functionality ?

@andrewsinnovations
Copy link
Contributor Author

Yes the intention is solely semantics, with _ and 404 having different meanings. I ran some tests with 404.sql and the functionality is the same. If you'd rather only offer 404 handling for unknown routes, I think that will work and can close the PR.

@lovasoa
Copy link
Collaborator

lovasoa commented Jun 20, 2025

Ok ! I have been thinking about ways to improve routing, I'll make my own PR and let you know !

@lovasoa lovasoa closed this Jun 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants