I did a bunch of work on this, and we need to finish it up. This will unify the way our whole loader system works to be basically like a D7 entity (it'll be pretty much a straight port, if we continue on the path I've started down). The VersioncontrolBackend class will be turned into a factory (which is always what I kinda had in mind), and we'll introduce (thank GOD) dbtng, so we can cut out much of the nasty query hairiness.
Initial patch is attached, and it's TRULY preliminary - it doesn't actually change anything (I don't think), it just starts adding the entity classes and tweaking the VersioncontrolBackend class. Go go go on this one!
Comments
Comment #1
sdboyer commentedReposting the patch generated by marvil in #528966-8: dbtng integration.
Comment #2
sdboyer commentedLots of progress on this locally, but this is a complex rewrite so I'm doing it in stages in git, and will commit back later.
Comment #3
sdboyer commentedIncremental patch, in case you wanna chase.
Comment #4
marvil07 commentedThanks for the patch, is really difficult to follow by your commits :-p.
Marking as it do not pass the test and I can not add a repo. Hoping to review this in the following days.
Comment #5
sdboyer commentedYup, CNW. It's not gonna pass the tests until they're rewritten, too. And yeah, I haven't worked on adding a repo yet, I'm still ironing out a number of different pieces.
Comment #6
sdboyer commentedOops.
Comment #7
marvil07 commentedjust to point the link to the branch where this is being developed now(aka readable history instead of huge patch)
http://github.com/sdboyer/versioncontrol/tree/entities
Comment #8
sdboyer commentedUpdated patch, showing incremental progress. About 80% done here...bearing down on the deadline 11 hours from now like a crazyman :)
Comment #9
sdboyer commentedChanging the title to reflect the way in which this issue is being ubiquitously used as the 'entities refactor' issue. When committed, this will introduce a change to the loader mechanism that is patterned after D7 entities and utilizes DBTNG. It also makes some major changes in how the existing classes are used, as well as radically expanding the responsibilities of the VersioncontrolBackend class to that of a factory for other entities.
Comment #10
sdboyer commentedI almost can't believe it, but...committed: http://drupal.org/cvs?commit=405402
The work is by NO means finished. Tests run, but on my local system they fail (though I suspect this might not be a problem with the refactor). We need a MAMMOTHLY large number of additional tests, stuff that puts all the controllers truly through the ringer. Documentation is patchy, sometimes woefully absent, and sometimes outdated. There are FIXMEs all over the place. The VersioncontrolOperationCache.php hasn't been eliminated yet (though all of its query helpers have), though mostly so that we have the code for the statistics gathering readily available. The true "philosophy" behind this refactor is only about 75% truly realized in the code. That philosophy is, "The API builds objects ONLY for single-repository operations, and never for listings. Any listings, anything that crosses from one repo (let alone backend) into another is done with straight dumb queries, and Views wherever possible." Also hugely importantly, all the write methods need to be written/unified for the various entities (got an issue for that - #879858: Unify entity C(R)UD ).
Nevertheless, the foundation is there, and it was time to put this code in, get it out in public. The really, really crucial thing to look at is includes/controllers.inc, as that's where all the entity controllers live. Changes will be made rapidly to the code now that it's in, though I'm going to let it cool for a few days before that starts happening. But I'm marking this issue fixed, as the initial commit is in, and we have, officially, moved over to using DBTNG and an entities-like system. WOOHOO!
Comment #11
sdboyer commentedSo, yeah, there are DEFINITELY problems with this, but don't reopen this issue - open new ones that are problem-specific. This one was only useful as a placeholder for the giant mess of stuff I just put in. Now that we can break it up into smaller issues, we should.