Transfer Survey, and the Results Are In!

I officially closed the Transfer
survey a short time ago, as results had slowed to a crawl.  Overall we
had 87 respondents, and it was really, really useful to get the

I can honestly say the feedback from this survey has changed the road-map for the next two releases of Transfer.

Transfer Experience

This was a really interesting set of questions.  41% of respondents say that they use Transfer every day, which is really exciting. Only 1 person responded with What is Transfer?, which hopefully means I'm doing a decent job of getting at least the name 'Transfer' in people's knowledge sphere.

people have been using Transfer for only 1-6 months (30%), while coming
second place (26%), 6 months to a year, and third 18% for 1-2 years.
Only 2 people have been using it for more than 2 years, but since the
project has only been around for 3, and the first year, itwasn't all that stable, I'm very happy with these results.

The version of Transfer that people are using totally shocked me! 73% of
people where running either 1.1 (which at the time was RC), or the BER
release of Transfer. 36% of people were running 1.0. Only 3 people were
running 0.6.3, which is a good thing, as it was a really buggy
release.  I'm so pleased to see the adoption rate is so high!

Other ORMs people have used

was another interesting section, in that Reactor scored the highest at
51%, and Hibernate came in second at 21%.  Interestingly enough, 31% of
people had never used an ORM before Transfer.

Transfer Enhancements

Not surprisingly, 58% of people that that Performance improvements were most important.  I wasn't
surprised by this, and I expect this won't change no matter how fast I
make Transfer.  The annoying thing is being constrained quite severely
by how fast ColdFusion can createCFCs, which isn't nearly as fast as I would like.

Several comparisons where made between Hibernate (and other Java/Groovy ORMs)
and Transfer, and while it is understood that Java will always be
faster, they still want comparative speed out of Transfer.  Not sure
how I'm going to get that to happen, but I know I will try my best.

To quote a survey taker: '…the
whole thing about not really being able to instantiate collections of
associated objects with decent performance – therefore you do your head
in constantly switching between object-think and query-think.  This is
the #1 reason I'd choose Java over CF for a decent-sized domain layer.'

fact of the matter is, he is right on what he's saying, and I hope its
something that Adobe listens to with future versions of ColdFusion.

enough, there were several requests specifically to be able to retrieve
arrays of Transfer generated Objects.  I had purposely avoided it due
to performance concerns, but I think this may be something that will
end up being discussed on the Transfer mailing list further, as there
were a few people who were interested in this feature.

Flex support was another hot topic.  I'm currently in the process of
learning Flex at the moment, so expect to hear solutions for this
common problem around the corner.

DB introspection was a huge draw card, with multiple comments like '…config file generation without using illudium…' and '…non-generative XML can be burdensome in large applications…',
which is all true.  In the next few releases we'll be looking at doing
property auto-generation from the database, and also providingDDL support for Transfer to generate your database for you.

mapping was also a big feature request (far more so than I had
originally ever thought it would be, and this is even before the recent spate of ORM
articles), and got me thinking about it a whole lot more.  To that
effect, expect to see Inheritance mapping as one of the next big
features in the next release of Transfer.

Some other interesting requests that came through were:

  • Annotations in Transfer XML data
  • Railo support
  • Generate methods for setting object properties from a struct
  • Query paging / Query limits
  • Bidirectional M2M compositions.
  • TQL aggregates

Support and Documentation

seems to be well received, with 46% of people giving Transfer support a
4, and 30% giving it a 5, where 5 was 'Very useful' and 1 was 'Not

That being said, ease of learning could be better, as
on a scale of 1 (Easy) to 5 (Really hard), the majority, 43%, sat in
the middle at, 3, although 34% gave it a 2.

From reading
comments, the big element to help Transfer learning, is examples,
examples, and when done, some more examples. Comments include: 'Beginner Tutorials, step-by-step type. Maybe even videos…', 'Lack of tutorial type documentation. Especially for advanced topics.', 'The examples on the site are a bit limited…', 'More examples, and more advanced examples…',
so the pathways are pretty clear.  I will be contacting members of the
Transfer community and contacting people who participated in the survey
to help with this.


I'll be finalising the road-maps for the next 2 releases of Transfer based on this feedback, however, I'm looking at moving to Skweegee from Project Tracker, so once I've made a decision in that area, and how to manage previously completed tickets and milestones, I'll get stuck in.

Thanks to all who participated, it was really useful to get the feedback!

Leave a Comment


  • Bob Silverberg | November 10, 2008

    Where are my annotations? I want my annotations! 😉

  • Kevin Roche | November 16, 2008

    I would not consider using Transfer without generating the transfer XML. I am not sure what benefit you get from goung from transfer XML to a DDL schema. Much more likely in my opinion that you would want to go the other direction. If you were starting anywhere else wouldn’t it be much more likely to be in CF itself? Can you create somthing to read property tags in CFCs and create DDL from them?

  • Mark Mandel | November 17, 2008

    Realistically, because when implementing your application, you should be designing your Objects first.

    Transfer shouldn’t just be a way to just get at and manipulate your database, it should be a way to automate and easily implement your intelligent domain model.

  • John Allen | December 7, 2008

    Auto generating the db… that would be VERY helpful. Been thinking about that for a while.

    Been knee deep in Transfer on my current job, every day I say to myself: "Self, Transfer totally kicks ass".

    Thanks Mark.

  • Rich Kroll | April 14, 2009

    Have you given any thoughts to support for distributed caching? I know that Sean Corfield posted something regarding using JMS for cache invalidations, but that only works when you have access to the CF event gateway (no railo, etc.). It would be great if there were a configurable cache layer in transfer (default, ehCache, memcached, etc.). This would remove the dependency on CF enterprise, and add support for other engines, and the ability to scale transfer to multi-JVM/server implementations.

    Thanks for a great tool!

  • Mark | April 14, 2009

    Unfortunately, with the way CFCs are serialised currently, it’s not really an option, as they do a deep serialisation.

    Considering the fact that TO’s have a copy of Transfer inside them, it would mean you would end up caching the entire object graph that goes from the cached object, back down to transfer, to it’s cache, and then back out to every object. (In reality it would fail, as much of this isn’t serializable, but you get the drift).

    You want to have a look at the TransferSync project:, I know it works with the JMS gateway, but it really is the best tool for scaling Transfer.

  • Rich Kroll | April 16, 2009

    Sadly, we can’t use TransferSync as we’re using railo for this project. Could it be possible that the TO could be updated to mark properties (or accessors) as transient, and then during the serialization process they could be excluded? I briefly started to scan the source and it appears that your architecture would support a different cache manager if the serialization problem could be tackled.

    Your thoughts?

  • Mark | April 16, 2009

    As far as I am aware, there isn’t a way to mark properties as transient, unless there is a feature that I’m not aware of?

  • Rich Kroll | April 17, 2009

    What I meant was you could possibly add a transient="true" property to the method definition and then access it via the meta data. This way you could iterate over a TO and build a value object that would end up being cached. It would add a bit of overhead to the serialization/de-serialization process, but could give the ability to inject other caching providers and may even allow pluggable "serializers" to go to XML, JSON, or whatever was needed.

  • Sebastiaan van Dijk | February 12, 2014

    Hi Mark,

    This is an old post, but then again so is Transfer 😉 Still, we’re using it in a large software package still running many clients. The question I have is if there still is documentation somewhere and active updates to bugs etc. We’re experiencing slow load-times and non-responsiveness when we want to perform simple actions against rather large database objects. Should we continue on this journey or refactor completely with some other form of ORM? If I can mail you our setup privately that would be good.

    Thanx up front!

    Greetings from the Netherlands