You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Slugs in URLs are similar to tagged ids, but incorporate part of the entity's data directly, i.e. Author firstName=bob might have an Author slug=bob-123, which looks tagged-ish, but isn't actually immutable (users can change the firstname, username, etc).
There are Rails gems that incorporate slugs into ActiveRecord, i.e. friendly_ids, so it'd be interesting to see if we could do something similar with Joist.
This would very likely just be a use case that was supported by a plugin, and not a core feature, but one could imagine a query rewriting plugin that would:
See a where = { author: "someString" } clause for an em.find/etc
Pattern match the some string has "probably/definitely a slug
Rewrite the query AST to be where = { author: { slugs: { slug: "someString" } } }, i.e. a join into the slugs table that keeps track of the 1-N slugs that have been created for the given Author
If we were super-fancy, the domain.id might start returning slugs, which at least for Joist would be fine because we've moved basically all of the internals over to idTagged to support maybe/maybe-not tagged ids.
The text was updated successfully, but these errors were encountered:
Slugs in URLs are similar to tagged ids, but incorporate part of the entity's data directly, i.e.
Author firstName=bob
might have anAuthor slug=bob-123
, which looks tagged-ish, but isn't actually immutable (users can change the firstname, username, etc).There are Rails gems that incorporate slugs into ActiveRecord, i.e. friendly_ids, so it'd be interesting to see if we could do something similar with Joist.
This would very likely just be a use case that was supported by a plugin, and not a core feature, but one could imagine a query rewriting plugin that would:
where = { author: "someString" }
clause for an em.find/etcwhere = { author: { slugs: { slug: "someString" } } }
, i.e. a join into theslugs
table that keeps track of the 1-N slugs that have been created for the givenAuthor
If we were super-fancy, the
domain.id
might start returning slugs, which at least for Joist would be fine because we've moved basically all of the internals over toidTagged
to support maybe/maybe-not tagged ids.The text was updated successfully, but these errors were encountered: