On Fri, Mar 19, 2010 at 3:38 PM, Jim Gay <[email protected]> wrote:
> Don't try to fix it. If a core spec is defined to expect things in a > default order but an extension changes the default, then those added specs > will fail. The only way around this would be to undefine the original specs, > but I'm not sure of a way to do that. > I'll add a +1 to Jim on that. The right way to handle this would be for the new find method to test and and see if an order clause was passed in, and use that clause if it was, while defaulting to position order if no other order is specified. (If the core spec insists on another default order, *then* it's time to address the idea of changing the core spec, as that approach is almost guaranteed to cause issues with extensions.) I've had lots of issues with interactions between both drag_order and reorder and r:children tags because of that. (For some items, I want descending order by date, for others I want a specific page order.) I'd planned on forking reorder to do that (I'm migrating a wordpress site with 150+ posts, and I'm sick of reordering them as I migrate them; the current state of reorder lets the "asc" and "desc" values through, but overrides the date_published order with position order) once I got the tests to run sensibly. I'm having trouble with that at the moment, though. Which means that the column doesn't exist. So it sounds to me like Anna is > merely seeing the result of the altered behavior with a position column, but > Arlen doesn't even have the position column. > Yep. I can run the migration and look at the test db and see the position column, but when I run the tests, the test db gets rebuilt *without* the position column, which I've verified. I'm still sure I'm overthinking this, and when I find out what's wrong I'm going to feel stupid, but so far I'm still mystified. Gonna put it down for a while and come back to it with fresh eyes. I haven't had a chance to really look into this, but I have seen the problem > before and can't recall how it was fixed for me (other than running "rake > RAILS_ENV=test db:migrate:extensions") That actually worked in one installation here, the 0.8.1 one. But it just stares at me blankly in the edge one. I'm sure I've screwed something up, and it's something simple. It just feels like it. (I'm liking the edge code better than 0.8.1 at the moment, so I'll probably be using it for the migration.) _______________________________________________ Radiant mailing list Post: [email protected] Search: http://radiantcms.org/mailing-list/search/ List Site: http://lists.radiantcms.org/mailman/listinfo/radiant Radiant: http://radiantcms.org Extensions: http://ext.radiantcms.org
