Packs+discussion
Gerry Gleason said:
Testing and test sets are getting some attention in this discussion, but I think this will need much more attention for modules to be reliable operationally. Basic functional testing is one thing, and we know we will need a variety of systems level tests that ensure features don't collide with one another.
Most critically, systems operations and admin tasks don't happen often enough of with enough variety to ever be fully tested. It is very difficult to simulate all the possible operational paths that may lead up to a certain systems state. I know that I have had to go into an SQL console to fix some problems that come up. That is to say, that code depends on representational regularities (invariant logical properties of the data) that may be broken by operational failures. We will need
utilities to: 1) verify the invariants are maintained. 2) Automatically fix corruption (i.e. like fsck) or 3) Additional tools to assist admins in fixing problems.
In this class is the way "uninstall" is very rarely tested, and potentially can break seemingly unrelated packages. Worse, stuff like db:migrate doesn't really have a function to back out these changes. If various modules require db:migrate type changes, we could have a "merge mess" in an environment (DB) that doesn't support merging or backout of steps very easily.
I put this in the +discussion card because I think most of it applies to what we'd want our testing to accomplish inside and outside of modules. might make for another Blueprint card?
--Ethan McCutchen.....Thu Oct 08 11:44:48 -0700 2009
If Wagn intends to move away from its relational database roots in the future, should support for something like CouchDB be implemented before the module hooks and API systems are designed?
--Marcus Estes.....Mon Oct 12 15:44:47 -0700 2009
That's an extremely good question and one which we've probably been answering too casually with things like "oh, we just need to make sure that the api and hooks are general enough to be portable." Clearly it could take us a good bit longer to get to 1.0 if we make this a prereq, but it may be worth it. Lew, I know this is an area of passion for you. Want to weigh in?
--Ethan McCutchen.....Tue Oct 13 07:14:06 -0700 2009
Has Marcus' question been considered further or is it too late now :-)?
Another benefit we could list:
let us all try out a variety of features and see which ones we may want to incorporate into the core database
--John Abbe.....2013-03-22 19:22:27 +0000
Strategically, we have to do 2.0 in order to be able to do low-level nosql (not the other way around).
Technically, the db interactions are pretty well contained behind WQL. I'm sure WQL will have to evolve at least somewhat to fit, but that's not a major consideration for the rest of the API.
--Ethan McCutchen.....2013-03-22 20:44:55 +0000
From Ethan, elsewhere: the closest thing to a list of packs is to look at the code: https://github.com/wagn/wagn/tree/master/lib/wagn/set For example, if you click on "type" you'll see all the types that have pack code associated with them. Similarly, you can go to https://github.com/wagn/wagn-cldstr to see all the client packs (click on wagn-clientname, then files-ws to see the pack file itself). If you decide to make a written list, please don't make it public. This is a case where inaccurate is worse than nonexistent, imo, and I guarantee we won't keep it accurate.
So, this is what is going to become Mod?
Yes, I've been pulling the best of it into mods
(Closing this)