Table Namespacing: Prefix vs. Prefix

[gossi]

Let's talk prefixes. There happens to be two views on prefixes both applied on table names. I roughly explain both and then talk about strategies about implementing them.

1. User prefix: Most users are given one database in their hosting plans, when they want to install two or more instances of the same application, they need to hope these apps can let their table names prefixed. Let's remember the popular wp_ prefix for wordpress, which can be changed easily in order to install more than one wordpress instances.

2. Package prefix: Given a packaged/modular schema. It can happen (because two or more developers operate independently) that there is one table with the same name in two packages (or even more). To avoid name conflicts it would be easiest to namespace each package and also the table names. A prefix per package seems the most reasonable here. Even if the entity is in two different (php-)namespaces for each package, also the table name must be namespaced (I'm a bit propel2 on this, dunno how propel3 would handle such a conflict). In propel2 there was a warning, that two tables have the same name (even though, they had different namespace and different prefix).

A table name would follow this pattern: <user_prefix><package_prefix><table_name>

Depending on how you used propel2 in the past, it either supported one or the other prefix, but not both, which I'd like to change for propel3 (I'd work on #36 in my free time - and this would make sense to incorporate).

Basically, the user prefix is something you'd extract to the install process and then write into the config file, which is read by the propel at runtime while the other is something the dev is putting itself on the schema during development. Moving this foward, what needs to be done:

Naming Conventions
Is prefix the best name for this? Or something like namespace or package but this will highly conflict with other propel concepts. Historically, prefix is probably the best here ;)
User Prefix: Alternatives would be: instance prefix or install prefix?
Package Prefix: Alternatives would be table prefix or entitiy prefix as it can be applied to tables as well?

Usage and Defaults

• If no package prefix is given, it is empty (should work fine).
• Package prefix can be given at <database> element on each schema.
• Package prefix can be overridden at <entity> level - yes or no?
• A table must be uniquely identified by prefix (table name) and namespace (php name) anyway there is a naming conflict.
• There should be a validator to check this (is there already one? I don't know, then these rules must be added).

Once we come to a conclusion, I'd start with this and #36.

[stevleibelt]

My two cents.

If no package prefix is given, it is empty (should work fine).

Prefix or "Table Prefix" is a well known term in database domain, I would stick to "prefix" or even make it bullet proof by naming it "Database Table Prefix".

Package prefix can be given at element on each schema.

Yes, and only there. If it would be allowed to change it on an entity level, it would end up like "you have to read the whole schema definition since there can be a package prefix change hidden somewhere on an entity level.

A table must be uniquely identified by prefix (table name) and namespace (php name) anyway there is a naming conflict.

Yes.

Best regards,
Stev

[gossi]

I discussed this with @marcj and we ended up dropping the user_prefix since hosting plans nowadays typically offer more than one database and stick with prefix(?) to allow some sort of namespacing within the database/schema.

[cristianoc72]

Closed via #83