> Well, depends on how deep you go with "compatibility." As far as the voting > stands so far anyway, the CFML Advisory Committee is calling ORM a "vendor > specific" feature, meaning the people involved with the CFML language > standardization effort (of which I'm one) don't see ORM as a core enough > feature at this stage to recommend full compatibility between engines.
I see what you mean. Not that I plan on switching back and forth between engines, but it would nice to be able to port an existing app over to a new engine and have things just work without too much tweaking. > Are you saying that implementing Hibernate *specifically* would be a huge > incentive, or if you had a great ORM solution at all, that's a huge incentive? For me, the biggest thing is not compatibility for the sake of compatibility or necessarily using Hibernate under the hood, but having a great orm solution in general. For me though, Hibernate just seems to make a lot of sense because a) the large community already behind it, b) the battle tested nature of a product that has been around the block and is in many production applications already. It seems that it could be plugged in faster and enhanced more easily if the orm functionality were built on such a strong existing core. > This is a big topic of course. Speaking personally, I find the syntax of the > Hibernate wrapper in CF 9 to be unnecessarily verbose, and the behavior in > some cases is rather "wonky" (to use a technical term). So again speaking > personally, I'd love to see a more streamlined syntax for an ORM solution as > opposed to compatibility for compatibility's sake. Yes, I agree that the syntax is nasty in the CF version. However, with solutions such as Bob Silverberg's base persistent object (http:// basepersistentobject.riaforge.org/), we can clean things up pretty nicely and still maintain compatibility. As you mention though, If the split solution isn't too much overhead from a development perspective, maybe it makes sense to offer some sort of option around that as well. I guess the bottom line is that I would just love to see a kick booty orm solution bundled into OpenBD, and I, for one, would consider it the most high impact feature above any others. And so if there is a tested, proven foundation already out there (Hibernate), why not take advantage of all that work and use it? Does it have to be 100% compatible with Adobe's version? Probably not. But would full compatibility be an extra nicety that would help users migrate existing apps over to OpenBD even more easily? Absolutely! Vince and Alan are right to open the door for discussion about whether or not orm is even the right solution. Personally, I think it is. It's widespread, proven, easy to learn and use, greatly reduces lines of codes, and leads to more flexible apps that are easier to maintain. If there's a better way to do it, I don't know what it is. I definitely prefer it over code generation hands down. As far as the GAE solution, it sounds really cool from what I've read, but certainly the majority of applications still rely on and be built with relational databases for now and likely into the foreseeable future. As far as Alan's comment about orm being another framework that managed to get bundled into the engine, I say great! To me this means less configuration and setup hassle and concern for both new and experienced developers looking to build great apps quickly. I'm glad to see the discussion underway, again for me it's the most exciting potential OpenBD feature because of its ability to help users build robust applications quickly and easily. Best, Brian -- Open BlueDragon Public Mailing List http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon mailing list - http://groups.google.com/group/openbd?hl=en !! save a network - please trim replies before posting !!
