Thoughts

[Phillip Senn]

Hal says that he fears what will happen when hibernate is introduced,
and I can say that my first impression is that hibernate completely
changes every thought process about how to develop in ColdFusion, as
does all Object Oriented development.
Instead of assigning a value to a variable, you call a function that
assigns a value to itself?
Requiring variables to become functions changes the very core of the
language.

Chapter 8, page 527-530 of the cf9 Developers Guide talks about doing
the most often needed requirement that an Application Developer has to
deal with - CRUD.

But I don't even know what to call the object returned by an
EntityLoad command.
ARTISTS = EntityLoad("ARTISTS")

What is that? An array? What happened to my query structure?
Hibernate: Makes me want to go to sleep and check back in a few months
to see what the community has decided.

[Tom Chiverton]

On Jul 14, 4:39 pm, Phillip Senn <phillips...@gmail.com> wrote:
> But I don't even know what to call the object returned by an
> EntityLoad command.
> ARTISTS = EntityLoad("ARTISTS")

Array of Entity ?

> What happened to my query structure?

Why is having a 'query structure' important ?

I know what you mean however- this is very new to many people, ORM
(Transfer/Reactor) being a fairly small group of people, compared to
all the CF devs out there. It's going to take a long time to bed in
and be accepted.

[Brian Kotek]

If you think of a query as an array of structures, this is almost the same thing. The difference is that you're getting an array of objects (that have properties and methods) instead. Not to branch off into a discussion solely on ORM, but I can say that first, wrapping your head around it really isn't too difficult. And second, it is so useful and powerful that you'll end up shaking your head in wonder when you think of how much work and boilerplate SQL it eliminates.

[Phillip Senn]

The other thing I don't like right out of the box is that if you dump
the results of an EntityLoad, you get things like Firstname, Lastname.
But to get their values, you have to call getFirstname() and
getLastname().

To me, that seems to not be true to a programming language, but more
like a framework that someone has custom built.

If cfdump displayed getFirstname() and getLastname(), I could at least
see Adobe's point-of-view, but don't call it one thing when it's
really something else.

[Matt Williams]

Phillip,

getXXX() and setXXX() are very common functions that you'll see across
many languages. I haven't looked at an actual dump of an EntityLoad,
but I have a feeling Adobe did that to show how the property/column
name ties to the data. In dealing with Hibernate in CF9 it will help
you to accept that any <cfproperty> and ultimately its corresponding
table column will be accessed by getColumnName() and setColumnName().

-Matt Williams

[Brian Kotek]

It's both. The *properties* of the object are firstName and lastName. But they are private (in the variables scope of the CFC). CF automatically generates public getter and setter methods for the properties, so that anything using the object has to go through the method interface instead of messing around with it's internal data (a key element of encapsulation).

[Phillip Senn]

I think I want to see getXXX() in the dump rather than XXX and
inferring that the way you get XXX is by using getXXX().
Example:
<cfscript>
geocoder=createObject("webservice","http://geocoder.us/dist/eg/clients/
GeoCoder.wsdl");
result=geocoder.geocode_address("1600 Pennsylvania Avenue NW
Washington, DC 20500");
</cfscript>
<cfdump var="#result#">

Here you can see getters are explicit: getLat() and get_Long().

On Jul 14, 12:20 pm, Matt Williams <mgw...@gmail.com> wrote:
> Phillip,
>
> getXXX() and setXXX() are very common functions that you'll see across
> many languages. I haven't looked at an actual dump of an EntityLoad,
> but I have a feeling Adobe did that to show how the property/column
> name ties to the data. In dealing with Hibernate in CF9 it will help
> you to accept that any <cfproperty> and ultimately its corresponding
> table column will be accessed by getColumnName() and setColumnName().
>
> -Matt Williams
>

[Sam]

I haven't looked at the new features of CF9 (including the Hibernate
integration) but I'd like to make a few points.

It seems to me that Adobe is complicating the language further when it
ought to be improving what currently exists. I'd argue that Adobe
should be considering Coldfusion in the same way as a developer should
a project. i.e. you focus on getting the core functionality to work as
well as possible and then you introduce new functionality only when
you have a very good business reason for doing so. Less is sometimes
better. Coldfusion's greatest asset is its' ease of use and simplicity
but it biggest weekness its' inflexibility. Hibernate integration
would seem to be something that would *need* to be flexible. Also
hibernate integration is something that is probably only needed on
larger projects. The developers on these projects should be capable of
using Transfer or Reactor or writing a similar ORM themselves, or for
that matter integrating with Hibernate through Java.

What this will inevitably lead to is some (many) developers not using
the right tool for the right job. Do you want a simple/light read-only
query? Do you want an iterator for object entities? Do you want a full-
on array of entity objects in memory? Let's see the performance
implications!

So then what about writing the sql, isn't this a waste of time? Well
sometimes writing the sql code yourself is *good*. If not, in many
cases using a code generator will suffice.

Adobe should ensure that any cfdump clearly defines the data in
contains, as Philip says. And Brian, although properties should be
encapsulated as you say, it is incorrect to say that Coldfusion
*needs* to use person.setForename() instead of "person.Forename". This
is Coldfusion syntax only not implementation. Adobe could invoke the
set/get methods automatically as is done in .NET today with
properties.

Also I think it is important to explain the importance of
encapsulation rather than just stating it. So to clarify Philip, the
reason to encapsulate the properties of the object is to ensure the
integrity of the data inside the object. For a tax calculator object
(like the one used in Coldspring examples) when you give the tax rate
a value the object should not allow you to set the rate to less than
zero or greater than one hundred say.

Philip, it isn't just Adobe who confuse the issue. Currently when
accessing properties of a C# object using Bluedragon.Net you get the
methods set_<property> and get_<property>. Oh well...

[Brian Kotek]

On Sun, Jul 19, 2009 at 5:39 AM, Sam <sam....@googlemail.com> wrote:

I haven't looked at the new features of CF9 (including the Hibernate
integration) but I'd like to make a few points.

How can you say that you haven't looked at the new features, and then continue with criticism of the new features?
 

It seems to me that Adobe is complicating the language further when it
ought to be improving what currently exists. I'd argue that Adobe
should be considering Coldfusion in the same way as a developer should
a project. i.e. you focus on getting the core functionality to work as
well as possible and then you introduce new functionality only when
you have a very good business reason for doing so. Less is sometimes
better. Coldfusion's greatest asset is its' ease of use and simplicity
but it biggest weekness its' inflexibility. Hibernate integration
would seem to be something that would *need* to be flexible. Also
hibernate integration is something that is probably only needed on
larger projects. The developers on these projects should be capable of
using Transfer or Reactor or writing a similar ORM themselves, or for
that matter integrating with Hibernate through Java.

Have you ever used Hibernate, Sam? The reality is that Hibernate is vastly more powerful and efficient than Transfer, Reactor, or anything that an individual developer could possibly write themselves even if they had years to work on it. Integrating with Hibernate directly though Java is an option, if you're willing to drop using CFCs and instead use Java objects. Of course, that's going to be far more complicated to implement and requires that the developer know Java. The point of CF wrapping Hibernate is to hide the majority of the complexity of using it and make it easy to harness its power. Again, since you admitted up front that you haven't even looked at this, what you're presenting here isn't an informed opinion. I'd suggest looking at it in detail and then revisiting this argument.
 

What this will inevitably lead to is some (many) developers not using
the right tool for the right job. Do you want a simple/light read-only
query? Do you want an iterator for object entities? Do you want a full-
on array of entity objects in memory? Let's see the performance
implications!

So the problem here is giving CF developers too much rope on which to hang themselves? If a developer incorrectly uses Hibernate, that is somehow CF's fault? That's like saying a developer who writes multiple inefficient SQL queries should be blaming the database. Since CF9 will allow you to do all of the above, it will of course be up to the developer to use the appropriate option. That said, Hibernate is a *very* highly optimized library, and the vast majority of developers will not run into performance issues. And if one is writing some reporting engine that requires manipulating thousands or tens of thousands of rows, then the same applies to both CF and raw Java: an ORM is not really meant to be used for large-scale data mining or OLAP processing.
 

So then what about writing the sql, isn't this a waste of time? Well
sometimes writing the sql code yourself is *good*. If not, in many
cases using a code generator will suffice.

Writing the SQL *is* usually a waste of time. In most cases, basic CRUD operations gain virtually nothing from being written by hand, and using a code generator just means more code to maintain. For cases where one does require granular control over the query, that's fine. Write the query yourself, or use HQL.
 

Adobe should ensure that any cfdump clearly defines the data in
contains, as Philip says. And Brian, although properties should be
encapsulated as you say, it is incorrect to say that Coldfusion
*needs* to use person.setForename() instead of "person.Forename". This
is Coldfusion syntax only not implementation. Adobe could invoke the
set/get methods automatically as is done in .NET today with
properties.

As you say, under the hood .NET (and Groovy) both invoke the automatically generated getters and setters whenever you manipulate a property. All I was pointing out is that the goal is to have external code interact with the object through its method interface, which is what .NET and Groovy are doing. They're just offering a small shortcut for doing it. If you really have a big problem with having to do person.getX() instead of person.x, or a problem with the dump not having the generated methods in it, then by all means go submit an enhancement request. To me, this is such a minor thing compared to everything else being discussed that I don't see any point to dwelling on it.
 

Also I think it is important to explain the importance of
encapsulation rather than just stating it. So to clarify Philip, the
reason to encapsulate the properties of the object is to ensure the
integrity of the data inside the object.

Hmm, since I said that a key element of encapsulation was "so that anything using the object has to go through the method interface instead of messing around with its internal data", how is what you just said different from what I said?

To sum up, I think it's premature of you to admonish these things until you actually look at them. If you look into the CF9 features and still have problems with them, then let the CF team know, or have a look at Railo or BlueDragon to see if they better fit your needs.

Regards,

Brian

[Sam]

Hi Brian,

Thanks for that reply :) I'm only playing devils advocate. Coldfusion
9 is still only beta and I haven't had time to look at it yet. When I
do I'll let you know. However I do believe Coldfusion should try to
complement other languages and not always try to compete.

I have just a few questions I hope you can answer:

a) Is Abode suggesting people use Hibernate without knowing about it
or that they should spend a full month reading all the documentation
(and that is assuming that they are a fast reader).
b) How much of the Hibernate functionality is Coldfusion implementing
would you say and how flexible do you think it is?
c) Is Hibernate an agreed feature of the CFML advisory board and
therefore something that will be implemented across the board (Railo,
Open Bluedragon, New Atlanta)?
d) WIll the hibernate functionality work whatever the Servlet/J2EE
server used (without configuration)?

Hibernate is definately an in-demard project. It is competing head-on
with container managed persistance (EJB3) in the J2EE arena and is now
getting recognised in .Net alongside Spring.Net, and is probably a
great project for any software developer to try to pick up. However
I'll still be interested to see how beneficial it will be to
Coldfusion hidden behind some cf tags.

I don't have any allegiance to Coldfusion, Railo, New Atlanta, or for
that matter CFML in general. I'd happily use the best tool for the
job. I like the language and will hopefully continue to use it but
that doesn't mean there aren't a hundred (well maybe ten) things that
annoy me about it every day.

Regards
Sam

[Brian Kotek]

Hi Sam,

On Sun, Jul 19, 2009 at 6:51 PM, Sam <sam....@googlemail.com> wrote:

Hi Brian,

Thanks for that reply :) I'm only playing devils advocate. Coldfusion
9 is still only beta and I haven't had time to look at it yet. When I
do I'll let you know. However I do believe Coldfusion should try to
complement other languages and not always try to compete.

There's nothing wrong with playing devil's advocate and identifying flaws. I was just saying it would carry more weight if you were speaking with some level of familiarity on the issue rather than on a gut reaction (for lack of a better term).
 

I have just a few questions I hope you can answer:

Sure.
 

a) Is Abode suggesting people use Hibernate without knowing about it
or that they should spend a full month reading all the documentation
(and that is assuming that they are a fast reader).

I'm pretty sure that Adobe's stance is similar to what it is with other integrated features, namely that for common use cases you don't need to understand a great deal about it at all. But if you need to, you can dig into the guts of it. Similar to how they integrated Vertiy and now Lucene: both of those products have gigantic manuals, but most people never need to care.
 

b) How much of the Hibernate functionality is Coldfusion implementing
would you say and how flexible do you think it is?

From what I've seen, they've implemented all of the major features that Hibernate offers, which includes the core ORM features, schema generation from an object model (which has always been one of the issues with the existing CF ORM offerings), lazy association loading, transaction management, ORM events, and second-level caching (a gigantic performance boon). The majority of this is exposed through the simple application-level settings and in the property declarations, and the underlying Hibernate configuration files are also available if necessary. So from an integration standpoint, I think they've done a pretty good job.
 

c) Is Hibernate an agreed feature of the CFML advisory board and
therefore something that will be implemented across the board (Railo,
Open Bluedragon, New Atlanta)?

I'm not sure if it is or not, but I know that Railo has been talking about integrating Hibernate for a while as well and I suspect we'll see that soon (maybe Sean or Peter can confirm).
 

d) WIll the hibernate functionality work whatever the Servlet/J2EE
server used (without configuration)?

Yes, it should. Hibernate is just a Java library, so it should work in any of the servlet containers.
 

Hibernate is definately an in-demard project. It is competing head-on
with container managed persistance (EJB3) in the J2EE arena and is now
getting recognised in .Net alongside Spring.Net, and is probably a
great project for any software developer to try to pick up. However
I'll still be interested to see how beneficial it will be to
Coldfusion hidden behind some cf tags.

Well, JPA was primarily created from Hibernate, and Hibernate is an open-source implementation of the JPA spec. It does, however, add additional capabilities that are not part of JPA (though I suspect they probably will be adopted since the majority of Java projects using an ORM are using Hibernate). Considering how much time people spend writing or trying to generate boilerplate SQL or using something like Transfer, I think the integration of Hibernate is a big deal and will become something that many CF'ers will look back on and wonder how they did things without it. Of course, time will tell.
 

I don't have any allegiance to Coldfusion, Railo, New Atlanta, or for
that matter CFML in general. I'd happily use the best tool for the
job. I like the language and will hopefully continue to use it but
that doesn't mean there aren't a hundred (well maybe ten) things that
annoy me about it every day.

There are plenty of things about CF that annoy me as well. But overall it's a pretty great platform. Further, the issues that I have with it are probably not the issues that the average CF developer has with it. I'm hopeful that the problems I've had with it in the past (mainly in the area of CFCs) are being mitigated in CF9, but we'll have to see.

Thanks,

Brian

[Sean Corfield]

On Sun, Jul 19, 2009 at 3:51 PM, Sam<sam....@googlemail.com> wrote:
> a) Is Abode suggesting people use Hibernate without knowing about it
> or that they should spend a full month reading all the documentation
> (and that is assuming that they are a fast reader).

The Hibernate integration is intended to be used without needing to
know anything about Hibernate. It's simple, slick and "just works".

> b) How much of the Hibernate functionality is Coldfusion implementing
> would you say and how flexible do you think it is?

All functionality is available. Nearly all core functionality is
available directly using <cfproperty> tags. If you really need
something exotic, you can drop into the .hbm files.

> c) Is Hibernate an agreed feature of the CFML advisory board and
> therefore something that will be implemented across the board (Railo,
> Open Bluedragon, New Atlanta)?

Hibernate is considered vendor-specific by the Advisory Committee
because it is an "unknown". It's not clear how well it will be
received by the community nor whether Adobe may need to change it in
response to community feedback. It was also considered a big burden to
place on vendors to require implementation as a core feature. The
Committee will review it in two years - for CFML2011 - and may elect
to move it from vendor-specific to extended-core (in which case it
will need to be documented / specified as part of CFML2011).

Yes, Railo has committed to providing integration with Hibernate (and
a number of other JBoss projects). We'll follow Adobe as closely as we
feel is appropriate and may offer additional / improved features based
on community feedback - or we may try to simplify it based on
community feedback. Again, this goes back to the Committee's position
on this feature.

> d) WIll the hibernate functionality work whatever the Servlet/J2EE
> server used (without configuration)?

Yes. That's almost certainly Adobe's intent.

> Hibernate is definately an in-demard project. It is competing head-on
> with container managed persistance (EJB3) in the J2EE arena and is now

Hibernate is the Reference Implementation for EJB3 I believe (so I'd
hardly call it "competing").

> getting recognised in .Net alongside Spring.Net, and is probably a
> great project for any software developer to try to pick up. However
> I'll still be interested to see how beneficial it will be to
> Coldfusion hidden behind some cf tags.

You clearly need to read the CF9 docs and experiment with it. As Brian
says, you're speaking from your gut right now and, on this feature,
that's not a good idea :)
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[Sam]

Brian / Sean,

Of cause what I'm saying is a gut reaction. As CF9 is beta and no-one
will have produced any production applications with it, I'd say
everyone's opinions are in some way gut rather than factual.

Also object persistence *is* different from searching. It is more
fundamental. You're also now opening up alternative implementations to
CRUD and unlike you I do think this could lead to problems. With
Verity/Lucene there is only one choice. In some cases a high level of
abstraction is good. In other cases blindly doing things without
knowing the impact is dangerous. I'd consider object persistence to be
the latter.

I don't buy into the statement that Hibernate is a must have for
Coldfusion developers. You'll even find a large part of the
Java / .Net worlds who don't buy into it, or ORMs in general for that
matter. Having now taken a look at the CF9 docs the implementation
will require a lot of learning from most developers and a far bit of
configuring. Coldfusion should be careful to not lose it's simplicity.

I believe divergence of CFML specs between vendors could be the
biggest danger to the language, in the longer term. Object persistance
isn't like Air / Livecycle integration (specialist Adobe topics), it
is fundamental.

I really don't get the reasons for the implementation. If you're
creating a seriously complex application in Coldfusion I'd suggest you
need to utilise Java or .Net in the back-end. Then if you want
Hibernate, it can be integrated natively. If we're saying that it is
needed for simple sites and applications, then there is going to be a
large learning curve and misuse. And frankly it isn't needed in this
case. Coldfusion developers need to be able to write SQL. They need to
be able to understand it. It may be that Adobe feel that it is good PR
to say they have integrated Hibernate into CF9. I'd suggest this is
misguided. If Coldfusion tries to do everything it'll end up doing
none of it well. I'll repeat myself, "simple is good". At least in
Coldfusion's case.

Regards
Sam

On 21 July, 00:16, Sean Corfield <seancorfi...@gmail.com> wrote:

> Railo Technologies US --http://getrailo.com/
> An Architect's View --http://corfield.org/

[Peter Bell]

On Jul 21, 2009, at 9:25 AM, Sam wrote:

> Of cause what I'm saying is a gut reaction. As CF9 is beta and no-one
> will have produced any production applications with it, I'd say
> everyone's opinions are in some way gut rather than factual.

Err, no. Many people were on the prerelease program and it is now
available as a beta. While not all issues have been identified and
while there is clearly more learning to do, there are plenty of facts
available. Many people *have* used the ORM features, and now that it's
in beta you can too so you can base your statements on experience of
using the feature rather than what you think it might be like.

> blindly doing things without
> knowing the impact is dangerous. I'd consider object persistence to be
> the latter.

That's true. I think people are going to get caught out by lazy vs.
eager loading and potential issues with either loading complete object
graphs on the one end or n+1 query problems on the other. Whenever you
use a new feature, you usually need to learn something new. You can
get into plenty of trouble with SQL if you select * without a where
clause on large tables and then filter using Query of Query - people
had to learn that if they didn't know anything about databases -
doesn't mean db integration into CF was a bad idea. You can also get
in trouble with locks, file operations and just about anything else.

> I don't buy into the statement that Hibernate is a must have for
> Coldfusion developers.

I'm sorry - who made that statement?! I thought it was being added as
an option for those who *wished* to use it.

> You'll even find a large part of the
> Java / .Net worlds who don't buy into it, or ORMs in general for that
> matter.

It's not a very large part at all. There are definitely use cases
where ORMs are non-optimal. One issue I'm dealing with is the memory
footprint of Hibernate. If you're building one large app, it's
nominal. If you want to host 200-300 separate applications with
separate db's it becomes an issue. There are also certain classes of
application where it's not the ideal fit. But I'd say for web apps in
the Java world, for many developers it's the default approach unless
you have a reason *not* to use it. .net is (as usual) a little behind
on that.

> Having now taken a look at the CF9 docs the implementation
> will require a lot of learning from most developers and a far bit of
> configuring. Coldfusion should be careful to not lose it's simplicity.

I think many users will be able to get away with very little
configuration, but it'll be interesting to see.

> I believe divergence of CFML specs between vendors could be the
> biggest danger to the language, in the longer term.

True, but not sure how it relates to ORM. The current ORM is vendor
specific, but I'd be surprised if all three engines provided radically
different implementations, and if ORM became popular enough it is
possible that the ORM implementation (or elements of it) could become
part of a core spec in the future.

> I really don't get the reasons for the implementation. If you're
> creating a seriously complex application in Coldfusion I'd suggest you
> need to utilise Java or .Net in the back-end.

I think that is the whole point. There are some applications better
written partially or fully in Java. Some, however are just ported to
Java to take advantage of Hibernate. Some of those will now be able to
stay in ColdFusion cutting down on the number of languages that a
company needs to support. Adding Java to an app substantially
increases training and maintenance costs if nobody on your team has
anything but CF experience.

> Then if you want
> Hibernate, it can be integrated natively. If we're saying that it is
> needed for simple sites and applications, then there is going to be a
> large learning curve and misuse.

What experience are you basing this on?

> And frankly it isn't needed in this
> case. Coldfusion developers need to be able to write SQL. They need to
> be able to understand it.

It depends on the app. For many applications, understanding SQL and
the details of ORM can allow you to make better implementation
choices, but spending lots of time writing and then re-writing CRUD as
your data model evolves is not usually the best use of expensive
developer time.

> It may be that Adobe feel that it is good PR
> to say they have integrated Hibernate into CF9. I'd suggest this is
> misguided. If Coldfusion tries to do everything it'll end up doing
> none of it well.

Really? CF Query is going to work less well now that Hibernate has
been added? Is cffile suddenly going to break? How exactly will adding
an optional feature decrease the utility or functionality of the
existing features?

> I'll repeat myself, "simple is good". At least in
> Coldfusion's case.

Right, making hard things easy. Always was the mission. Now hopefully
hibernate will be a hard thing that is easier. As with everything some
people will misunderstand and/or misapply it and have problems and
others will apply it to suitable use cases and hopefully get greater
value from their investment in ColdFusion.

Do let us know though as you start to actually use the feature how it
works for you and whether you run into any unexpected issues.

[Sam]

Hi Peter,

People using CF9 pre-release are probably not the average developer.
Also using something in a test environment is very different from
watching it perform in production. A stepping stone yes but not the
same.

".. I think the integration of Hibernate is a big deal and will become

something that many CF'ers will look back on and wonder how they did

things without it." - Brian

I think people are simply confused if they port a Coldfusion app
*just* to make use of Hibernate. I'm a big fan of using Coldfusion
alongside Java or .Net as to me this offers the best of both worlds.
Is a situation where Coldfusion *can* do everything but just isn't
great at some of it better?

What I'd *like* is for the time and money to be used differently. I'd
rather they improved current weaknesses, fixed bugs, improved
performance, rather than add new features.

I don't really get the whole "I'm a Coldfusion developer. I can't do
Java or Ruby or PHP?". A good developer should have a core
understanding and experience that spans most languages. A good
developer should not be tied to one language they should choose the
best solution in every instance, although in reality this is rarely
the case I admit. Can't the message be it's good for Coldfusion
developers to grow beyond the CF world. To a large part, I choose to
code in Coldfusion because I like to, not because I have to. It's
always good to have alternatives.

Regards
Sam

[Brian Kotek]

On Tue, Jul 21, 2009 at 9:25 AM, Sam <sam....@googlemail.com> wrote:

Brian / Sean,

Of cause what I'm saying is a gut reaction. As CF9 is beta and no-one
will have produced any production applications with it, I'd say
everyone's opinions are in some way gut rather than factual.

Well, no, since there's already a barrage of solid info on it being written, and since you can download the beta and run it. I'd think you'd want to at least install it and run some simple examples before you leap to conclusions?
 

Also object persistence *is* different from searching. It is more
fundamental. You're also now opening up alternative implementations to
CRUD and unlike you I do think this could lead to problems. With
Verity/Lucene there is only one choice. In some cases a high level of
abstraction is good. In other cases blindly doing things without
knowing the impact is dangerous. I'd consider object persistence to be
the latter.

What is "more fundamental"? If your site revolves around searching data, I'd imagine you'd say search would be far more fundamental than object persistence. The are definitely choices with Verity and Lucene, not only could you create your own search yourself (which sounds like "write your own queries"), you could use another search service (Google, enterprise versions of Verity, etc.), and even within the integrated versions there are a lot of options depending on what you need to do. As someone who has worked with the enterprise Verity server, I can tell you that the number of options is extremely large. I can also assure you that it is very, very easy to "blindly do things" with the Verity integration that can cause major problems. Basically, you're trying to present this as some kind of apples to oranges comparison, when I would say they are much more similar than different when it comes to CF wrapping complex features.
 

I believe divergence of CFML specs between vendors could be the
biggest danger to the language, in the longer term. Object persistance
isn't like Air / Livecycle integration (specialist Adobe topics), it
is fundamental.

The CFML spec is already not applied the same way across vendors, so why is ORM some special case? Again you say it is "fundamental" (which sounds like a recognition of its importance?), but what does that mean? I don't really follow what you're trying to say here.
 

I really don't get the reasons for the implementation. If you're
creating a seriously complex application in Coldfusion I'd suggest you
need to utilise Java or .Net in the back-end. Then if you want
Hibernate, it can be integrated natively. If we're saying that it is
needed for simple sites and applications, then there is going to be a
large learning curve and misuse. And frankly it isn't needed in this
case. Coldfusion developers need to be able to write SQL. They need to
be able to understand it. It may be that Adobe feel that it is good PR
to say they have integrated Hibernate into CF9. I'd suggest this is
misguided. If Coldfusion tries to do everything it'll end up doing
none of it well. I'll repeat myself, "simple is good". At least in
Coldfusion's case.

Simple is good. Wiring a Java back end into a CF application is not simple. It is very far from simple. I don't see why the only options need to be "do it the hard way" (write/generate your own SQL) or "do it the hard way" (build everything in Java). What the ORM integration offers is an easy way for most people. You say CF developers need to be able to write SQL. Well, there's a lot of people out there who can't write moderate or advanced SQL. There's a lot of people who write multiple queries with nested cfloops because they don't understand joins or virtual tables. SQL has a large learning curve to learn thoroughly. It has a large potential for misuse (and, indeed, is the cause of almost all performance problems). Again, you're trying to paint the ORM integration as somehow different, when it isn't. People might be more familiar with SQL just because they've seen it for a long time. But it has the same potential for misuse as anything else.

Also, just a nitpick, it's "ColdFusion", not "Coldfusion".  ;-)

[Sean Corfield]

On Tue, Jul 21, 2009 at 7:42 AM, Sam<sam....@googlemail.com> wrote:
> People using CF9 pre-release are probably not the average developer.

Actually Adobe works pretty hard to include "average developers" in
its prerelease programs.

> Also using something in a test environment is very different from
> watching it perform in production. A stepping stone yes but not the
> same.

Hibernate is well tested in large-scale production applications and it
sounds like the CF Team have done a huge amount of work to ensure
CF/Hibernate performance is good.

> I think people are simply confused if they port a Coldfusion app
> *just* to make use of Hibernate.

Not sure what you mean by that... port a ColdFusion app from where to
where (or what to what)?

> I'm a big fan of using Coldfusion
> alongside Java or .Net as to me this offers the best of both worlds.

Which puts you in a VERY small minority.

Most CFers - the VAST majority - do not know Java or .NET so if it
isn't CFML, they can't use it. Adobe's integration of Hibernate
provides a way for those developers to avoid writing a lot of
repetitive CRUD SQL and even to have the DB updated automatically as
they evolve their schema directly in CFML (using simple CFCs).

> What I'd *like* is for the time and money to be used differently. I'd
> rather they improved current weaknesses, fixed bugs, improved
> performance, rather than add new features.

As Adam recently said, the first part of each release cycle is spent
doing precisely that. Then they move on to adding features that their
customers have asked for.

> I don't really get the whole "I'm a Coldfusion developer. I can't do
> Java or Ruby or PHP?". A good developer should have a core
> understanding and experience that spans most languages.

Ah, well, there's the rub. By your definition, the vast majority of
CFers are not "good developers" then.

> Can't the message be it's good for Coldfusion
> developers to grow beyond the CF world.

Sure, and I've been advocating CFers learn new languages for years.
But the fact is, the vast majority of the ~800k CFers out there are
monolingual.

--
Sean A Corfield -- (904) 302-SEAN

Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/