altering default user table

[wr1138]

What would be the best way to approach the addition/subtraction of columns to the default user table? Creating an alternate login component with it's own table? Or...? Seems like the specs for user table would be apt to change quite a bit from install to install...

[counterpoint]

It's beyond the resources available to me at present to go nearly as far as I would like on database handling.

One small point is that for a while now I've been trying hard to write SQL such that it doesn't demand more of a table than is absolutely necessary. In particular, INSERT statements specify the fields that are to be given values, leaving the possibility that other fields may exist and be given defaults. Also, all table definitions have defaults wherever possible.

Aliro helps quite a lot by providing database methods to alter tables easily, adding or removing fields, or giving information about tables.

Ideally, I would also like to have a way to define tables that is more flexible (and can be manipulated) than the bare SQL table create statements that are currently used in the packaging XML. Probably an XML form, but I'd prefer to follow an existing standard if possible.

[wr1138]

Originally Posted by counterpoint

One small point is that for a while now I've been trying hard to write SQL such that it doesn't demand more of a table than is absolutely necessary. In particular, INSERT statements specify the fields that are to be given values, leaving the possibility that other fields may exist and be given defaults. Also, all table definitions have defaults wherever possible.

Yah, big fan of SET here as well

Originally Posted by counterpoint

Aliro helps quite a lot by providing database methods to alter tables easily, adding or removing fields, or giving information about tables.

Worried about the side effects of altering that main user table...upgrades, etc...

Originally Posted by counterpoint

Ideally, I would also like to have a way to define tables that is more flexible (and can be manipulated) than the bare SQL table create statements that are currently used in the packaging XML. Probably an XML form, but I'd prefer to follow an existing standard if possible.

Would it be "good" to just make that user table broadly inclusive for now?
As in, add all the usual columns (and then some) -
street, unit, city, state, country, company, meta1, meta2, meta3, etc etc

[wr1138]

Or maybe a better way would be to treat the installer-person as a special case, leaving just enough code in the core to handle that 1 installer/admin, and the rest anonymous users by default...then the user table could be created by an extension like com_registration, or a new com_users. Seems like it has to come out of the core to be easily extensible and survive upgrades after alteration.

[counterpoint]

Is there going to be any answer to questions about the potential for future conflict in customization? It's a big question, and worth continuing to worry at.

Having good methods for database modification still seems a significant benefit, but not something that solves all the problems.

Aliro creates the initial admin user, but there is no requirement to install user management at all after that. Some sites don't need it.

[wr1138]

Originally Posted by counterpoint

Is there going to be any answer to questions about the potential for future conflict in customization? It's a big question, and worth continuing to worry at.

Having good methods for database modification still seems a significant benefit, but not something that solves all the problems.

Aliro creates the initial admin user, but there is no requirement to install user management at all after that. Some sites don't need it.

Yes, but decisions regarding user table schema have been hard coded
at installation in aliro_general.sql, which seems very much in contrast to general principles driving Aliro design. Sure, the table can be altered later, but that forces a confrontation with upgrades. I'm wondering why it's a good idea to set that schema at installation.

The notion of sites without defined users seems to speak against the need to initially define user table as well.

Would it not be better to define that table in the context of an optional user module? That would open the possibility of Aliro Core upgrades that don't have any need to touch the user table or reset/append it's schema, and allow arbitrary fields that are undoubtedly going to be required.

Unless of course, I've failed to consider some factor...

[counterpoint]

Well, your comments prompt a swift review of what is in the initial installation of the general database. If we ignore the tables that are created to provide for backwards compatibility, the current list is:

#__folders
#__messages and #__messages_cfg
#__remosef_config and #__remosef_uri and #__remosef_metadata
#__tags
#__users

The justifications for them could be debatable, but they go as follows:

The #__folders table is intended to provide a site wide tree structure (of arbitrary size and shape) into which content of any kind can be slotted. Until I tried to implement this, it seemed a good idea in principle. Mambo had a section/category 2 level tree structure that was supposed in theory to fulfill a similar function. Looking back, I'm not sure that using a single database table really led to any meaningful integration. And attempting to fit Remository into a site wide folder structure convinces me that it is harder than at first it appears. This is placed in the general database on the assumption that people will need to include it in joins.

#__tags is intended to complement #__folders by providing a site wide tagging system that could be used by any kind of content. Tagging provides for the sort of attributes that an item of content could have many of, as opposed to the folders, which are intended to be mutually exclusive choices. Again, may be used in joins.

#__messages etc. is intended to provide the basis for any PM system and the possibility of implementing a rudimentary PM system within the framework. Thinking (a bit superficially) about this suggests that maybe I should listen to my own advice and concentrate on standardizing APIs rather than database tables.

#__remosef etc. are the tables used by the SEF mechanism that does the traditional Mambo/Joomla style transformation of query strings into pseudo-directory URIs. It is in the general database for no obvious reason - perhaps because SEF ought to be something that could be removed and replaced by alternative software. And only the CMS framework should need to access the core database. Lately I've been thinking that query string transformation ought to be obsolescent, and replaced by the direct handling of URI strings, starting with the facilities relatively recently added to Aliro. (There will be a new chapter on SEF and REST in the 2nd edition of my book).

#__users is a special case, in that there is a table for users in both the core and general databases. The core database has the passwords and salts. The general database has all the rest. The passwords are in the core database for security, and the rest in the general database as it is frequently used in joins. Here I've maybe been too involved in the detailed issues of how to make this work to look enough at the overall design questions. At present, the general user table relies on the core table to handle the auto-increment generation of keys. The code to access both databases for a single user object is moderately complex.