On Wed, May 18, 2016 at 02:23:01PM -0400, Stephen Michel wrote:
> I don't understand exactly why it's a corner case. Under the current system,
> wouldn't /p/snowdrift/ eventually be coded the exact same way as any other
> project, so new projects would be prevented from using `snowdrift` as a slug
> in the same way that they'd be prevented from taking the slug of any other
> existing project?

N.B. I'm using the coqdoc convention of putting code in [square braces].

No. As it's implemented now,[SnowdriftProject] is in its own data type, defined
in config/models. In real terms, this means that there's a separate table in the
database called [snowdrift_project]. The [snowdrift_project] table only has one
row, which is inserted manually somewhere in the current source tree. [Project]
will eventually be a separate data type in config/models (and therefore have its
own table in the database).

[Project] will have a uniqueness constraint on the slug, much like how [User]
has a uniqueness constraint on the email. This uniqueness constraint is enforced
at the database level. Yesod and its database library (Persistent) only take
care of formatting database commands, and protecting against some security
threats, such as SQL injection.

The key thing here is that [Project]'s uniqueness constraint won't extend to
[SnowdriftProject]. They will likely not even have the same data structure.  For
instance, [SnowdriftProject] doesn't need to have the concept of a "slug",
because there's no dynamic routing to be done.

Therefore, were we to insert any additional constraints, they would need to be

1. Enforced at the database level, and therefore expressed through Persistent,
   or (maybe) a migration.  This is difficult at best, and probably not
2. Enforced at the Haskell level. This would mean defining a separate type, 
   [ProjectSlug], which would be a wrapper aroung [Text]. We'd then have to add
   code in the constructor of [ProjectSlug] specifying that the [Text] in the
   slug couldn't be equal to "snowdrift". Haskell doesn't really have the
   concept of a "constructor", so we'd have to use some type hackery,
   introducing even more performance overhead and code complexity.
All of this would be avoided if we just changed the route.

Peter Harpending <pe...@harpending.org>

Attachment: signature.asc
Description: Digital signature

Dev mailing list

Reply via email to