Not much to say to that :) On 12/3/09, Baz <[email protected]> wrote: > 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 !!
