Oh I see, so what other orm would you consider integrating? It seems we both agree that rolling your own probably isn't the best way to go.
1. Integrate hibernate exactly as ACF 2. Integrate hibernate differnetly from ACF 3. Integrate another orm (which one) Is that right? On 12/3/09, Matthew Woodward <[email protected]> wrote: > On Thu, Dec 3, 2009 at 3:26 PM, Bassil Karam <[email protected]> wrote: > >> Perhaps not, but then how are they going to be compatible? The big hairy >> difficult pieces that involve caching, synchronization, optimization and >> when the framework interacts with the db, all need to be perfectly >> identical >> otherwise things will simply behave differently and not as intended. >> > > But the question is not as intended by whom? > > >> What data is available when and where is very delicate to an app. The way >> I >> see it, even if OpenBD did choose to implement Hibernate, it would still >> be >> a fantastic feat to have it perfectly compatible with ACF - imagine >> without. >> > > The discussion seems to be taking full compatibility with CF as a given. I > don't think it is, and that's all I'm trying to point out. I for one would > argue that there are issues with the way Hibernate functionality was > implemented in CF, so do we replicate those issues for the sake of > compatibility, or do we look at creating a solution that we feel is better? > That's a discussion worth having. > > Part of the problem is we're talking about all of this in the abstract and > assuming there will be problems, compatibility or otherwise, if the end > solution doesn't wind up being Hibernate. That isn't necessarily the case. > > My personal opinion is that CFML developers should have worked much harder > on leveraging Hibernate a long time ago. I started a project called > cfhibernate eons ago (CF 6.1 was brand new if I remember the timing > correctly) but unfortunately it was ahead of its time. My thought at the > time was that reinventing the wheel in CFML wasn't the way to go since > Hibernate was already pretty mature even back then, and since CF runs on > Java, it made more sense to leverage Hibernate. I wrote a sample app that > illustrated how to get this all working if you wrote your model in Java, and > Kurt Wiersma even had a nice little translation process between CFCs and a > format that could be persisted by Hibernate. It was promising, but at the > time it was WAY too much of a pain to even get Hibernate playing nice with > CF. This would have been much easier to accomplish had OpenBD been available > back then. > > >> >> Maybe OpenBD's niche could be to provide the system of plugging in an ORM >> rather than develop the ORM. >> > > Again with the assumptions. ;-) There are options other than "use Hibernate > or build your own." Building something is of course one option, but let's > not assume because I'm trying to point out that Hibernate isn't the only way > to solve this problem that the only alternative is to build our own version > of Hibernate. > > >> There would be a defined API and a way to gather all the config data from >> the CFC's, but it would then be up to a 3rd party ORM provider to make it >> all work. Apps would still be dependent on the underlying ORM that was >> chosen, since (as I've been saying) it is too complicated for them to be >> perfectly cross-compatible - but at least syntax and configuration would >> be >> consistent and easy to learn between them. We'd start with a Transfer mod, >> then Reactor, then eventually an independent project would arise that aims >> to do it with Hibernate and make it compatible with ACF. >> >> > My own personal opinion--given the overhead associated with the CFML-based > ORM solutions, I don't think this is the way to go. No offense to Mark or > anyone involved with Transfer and Reactor (hats off to those guys for doing > all this hard work!), but to my mind moving forward these solutions will be > less important as all the engines integrate ORM. These were both > fantastically useful tools and will continue to be for the applications that > are currently leveraging them, but as ORM matures in the CFML engines I > think the usage of the CFML-based ORM frameworks will decline. > > -- > 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 !! -- 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 !!
