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 either 1. Enforced at the database level, and therefore expressed through Persistent, or (maybe) a migration. This is difficult at best, and probably not possible. 2. Enforced at the Haskell level. This would mean defining a separate type, called [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>
Description: Digital signature
_______________________________________________ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev