Structure Change
Working repo: https://github.com/GerryG/wagn
I'm going to break up what I have so far based on the found organization in the initial attempt at removing the cardtypes table dependency. It turns out that isn't the first step you need to take. I have the work so far on the branch 'structure_experiment' and will now cherry pick from that to a new 'structure_change' branch in smaller chunks, and in a more sensible order.
I think it makes sense to do this a bit backwards from how I started out. If I first bring in the changes to do all the extensions based on card_id and codenames in the cards table, then not much really changes internally, except that the extension_(type/id) fields and codename (login or class_name) will be ignored in the extension tables in favor of cards.codename.
I think I'll get just that part working, then probably see about either the main card cache or the cardtype caches next.
Goals of the Refactor
1) Remove Cardtype as an "extension". Use type_id over type (but keep type in the db for a later refactor after the structure change is well tested). 2) Use card_id as the linking field for all extensions, even ones we are leaving in for now. When this is complete, it should be possible to remove the extension_type and _id fields. Table changes for this 1) Add card_id field to users and roles table. 2) User_id and role_id in roles_users table are now both card_ids. 3) In the permissions table, the party_id is now the card_id of a role card (I guess now it will be easier to have parties be other types). 4) Codename now has to be actively updated in the cards table, and the values in the extension tables (including users:login and cardtypes:class_name) all have to be updated in cards. Builtins: Note that we will also have to add builtin cards to the DB so they can have codenames. Or they may not have to be in the DB, but if they are, use the DB entries. It may be better to handle these as entries that are loaded and locked into the cards database, and reloaded at initialization if they are broken. 3) Fetch from caches based on card_id. For the main card cache, I was planning on using both id and key based hash lookups for cards in memory. User and Role caches based on card_id only. 4) General cleanup of internal API for find/fetch, etc. This is all trying to go towards a single model of cards with optional extensions. I've thought about it a lot, and I think the main issue is just removing the polymorphic association with the extension classes, and replacing them with card based links. In other words, if you have an extended type, the Card::<extension> class has to be able to load it from the card_id and type of the main card so that any extension is "part of the card". If I had a better picture of this before I stared, I may have taken a slightly different approach, but I think all of this is necessary to get to the kind of stable API that we want. Once permissions are card_id based, it will be easier to do the permissions refactor. We may (initially) keep something like the permissions table for efficiency, or we may find another approach works better. I think that being able to fetch cards based on card_ids will lend itself to having various attributes on the in-memory card-model that hold the card_id of various related cards (templates, permissions, base class, account, roles).