Thanks,
Tom
At 07:30 PM 12/3/2009, you wrote:
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 !!
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 !!
