Let me preface all of this by stating that I'm playing devil's advocate and this in no way implies that any firm decisions have been made on this issue (at least not to my knowledge). All opinions expressed here are my own and do not in any way reflect any official position of the OpenBD project on this issue. (I know, probably being overly anal, but I'm seen way too many discussions get truncated and taken out of context if one isn't careful, so I don't want this to turn into someone twittering "omg OpenBD isn't going to be compatible with CF 9 orm!!!11")
With the legalities out of the way ... ;-) On Thu, Dec 3, 2009 at 11:24 AM, Brian FitzGerald <[email protected]>wrote: > To me this is by far the bet > feature in CF9 and is something I would really love to see implemented > in OpenBD. > In theory it's a great feature, but of course it's not without some issues in its implementation. If you read the blogs, etc. there's quite a mixed bag of opinions on this. > > It appeared in the old thread that you guys are considering > replicating much of the functionality w/o using Hibernate under the > hood? I'm not an orm expert, but it seems to me like this would make > it harder to maintain compatibility moving forward 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. Syntax-wise, I suspect all the engines will tend to lean towards compatibility with CF 9 (which is not great IMO, but more on that later). In terms of under the hood features and behavior, to me that's up for debate. I'm not saying any decisions have been made one way or another, but just as an example, if a solution that's syntactically the same can offer 90% of the features but perform better and be simpler to implement, that has to be weighed against full compatibility and the extra effort, performance degradation, etc. that might come along with that for the extra 10% of the features. Or what about a solution that syntactically is much less verbose but still gets the job done? Again, just so it's clear, this is all hypothetical at this point. Just offering my opinion on things. > and could also > limit some of the powerful features that CF9's orm offers. As always we're going to be driven by what our users most want and need, and we absolutely value everyone's feedback on this issue. > Is it > still up for discussion to have CF9 orm implemented in OpenBD with > Hibernate behind the scenes? Certainly--I for one would love to hear what people think on this issue, and as we move along towards implementation we'll be wanting to gather even more feedback. > Again, I for one would love to see it, > and would consider it a huge incentive to use OpenBD more in the > future. > 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? 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. That being said, syntax compatibility is probably in everyone's best interest (unfortunately; maybe we can offer a split solution and let people choose). 100% functional and behavioral compatibility, to me that's up for debate because if the pros of implementing things differently outweigh the cons, I'd like to see that at least debated so we can get everyone's feedback. -- Matthew Woodward [email protected] http://mpwoodward.posterous.com identi.ca/Twitter: @mpwoodward Please do not send me proprietary file formats such as Word, PowerPoint, etc. as attachments. http://www.gnu.org/philosophy/no-word-attachments.html -- 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 !!
