My point was more that if you start mucking with the generated code that a framework produces then you lose a lot of the benefits of the framework (because you're invading the framework's black box). At that point, you're basically using the framework as a static generator, which is fine, but reduces the utility of having the framework to begin with.

In PIER, I happen to tweak a lot of generated SQL, simply because machines are horrible about dealing with every edge case, so I don't even bother trying to program the generator to handle them. As such, any kind of automated solution would be more cumbersome than it's worth, but a static generator is perfect. Combined with vendor branches, it makes for a very easy to work with setup. That was my main point.

Basically what I've got is a custom Reactor-like product that doesn't have the ability to do anything dynamically. It generates only when I tell it to, never automatically. It's also tuned to do some PIER-specific generation. I could easily have started with Reactor and customized (and saved myself a lot of work, no doubt, judging from the digging around I've done in Reactor), but unfortunately Reactor came a few years too late.

I think Reactor (and Arf, etc.) are great products to have available to CF developers. They're just no a be-all end-all answer to persistance issues, and there are ways to make other techniques approach the ease of use those frameworks offer.

Just so I understand, the only complaint you really have with Reactor is the inaccessibility of the base generated objects? My real answer to that is that Reactor is not intended to keep you from having to code stuff. It’s whole purpose is to reduce the amount of tedious, repetitive coding you’d otherwise be doing.

Regarding speed, reactor shouldn’t have much more overhead in production mode than a typical factory CFC. There is a little overhead related to making the core CFCs database agnostic, but I’m working on that.

Anyhow, I’d love any feedback you might have. Reactor’s not for everyone (nor for every project), but I’d like it to be as good as it could be.

The main problem with this is you can only tweak stuff at the method level. I.e. if you need to change behaviour of the generated code, you can only do it by wrapping or replacing a method. No finer-grained control is available. In many cases, that's sufficient, but not always. An example would be a entity property that has a different type than the field in the DB. No big deal to override the get/set pair, but the UPDATE and INSERT statements don't need to be totally rewritten, just that one fields needs modification.

Obviously the idea has a long way to go, but it does allow regeneration without needing as much merging work and keeps the developer in absolute control. There are a lot more pros and cons as I keep thinking about it, but I have considered implementing it on a small scale to see how powerful it would be.