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).
Thx for posting this (I don't follow all of it in gory detail, but appreciate being able to stay up on changes to the internals). Does this relate to an existing ticket on http://www.wagn.org/wagn/Wagn_1_6 or to a new ticket, say, use card_id as the linking field for all extensions ? --John
Yes, new tickets. I really should have created them before diving in, but I didn't really know exactly where I was going when I started.
The plan is to create a ticket for each major chunk of this work, and I'm not sure how many. I'll use your link to create a ticket for the first chunk when I start to document it.
Thanks,
--Gerry Gleason.....Sun Dec 26 03:06:18 -0800 2010
It relates to this document that has notes about intended changes to the data structures in the DBs: https://spreadsheets0.google.com/ccc?key=tLm3EzjAMKlnSoIjbGOO7cQ&hl=en#gid=0 If there are tickets related to this, they may also tie in to this group of tickets.
--Gerry Gleason.....Sun Dec 26 04:25:41 -0800 2010
Branch is card_id_codename
--Gerry Gleason.....Fri Jan 21 08:55:34 -0800 2011
Renamed the branch to 'codename'
--Gerry Gleason.....Wed Feb 02 05:20:19 -0800 2011
Is this an existing or new Blueprint (or part of one)?
--John Abbe.....Wed Feb 02 12:16:17 -0800 2011
Not sure, but it probably should be. Maybe Unified view handling should be linked to the inclusion refactor.
I think we need a Blueprint for cardnames as a place for all the design elements connected to cardnames, keys, codename, plusses, etc.
--Gerry Gleason.....Wed Feb 02 13:00:19 -0800 2011