Elliot, I think you're absolutely right, at least at this point. I'm pulling from both the text and Mark's comments in these two blog posts for a lot of what I'm about to say:
http://www.firemoss.com/post.cfm/does-coldfusion-have-no-real-orm- frameworks http://www.firemoss.com/post.cfm/what-makes-a-framework-an-orm What I'm hoping will come of this is that Transfer will eventually include an object factory as well as a persistence mechanism. Mark has already said he's looking at several enhancements to future versions of Transfer to include inheritance mapping and hopefully eventually enhancements to allow things like bidi m2m joins. Granularity needs to be on the map so you can define 2 or 3 objects from one table, but I don't see that as insurmountable... maybe I'm wrong but still, it doesn't seem that far fetched. Hell, if I could make sense of the Transfer codebase (which is only function matter of time and effort on my part) I'd be more than willing to help add things like granularity to the framework, and allow the addition of objects to the factory that aren't included in the persistence scheme. Things like adding an object definition to the Transfer config without a table="" attribute means that the object is treated as a plain old ColdFusion object. Adding property tags with a ref="" attribute would allow you to associate these objects with other objects and intermingle the persistence tools with the object factory tools. It would still allow Transfer to generate many of the methods, even retaining the m2m, m2o and o2m terminology to create collections of other objects... I see this working very well and allowing Transfer to fill a need that's been around since ColdSpring gained fame and fortune: acting as an object factory for transient objects. I also don't think it would be out of line to contemplate Transfer being able to support a columns="" attribute to create a solution to the granularity problem, or, possibly, adding subordinate objects to the object definitions to be able to accomplish it. Doing it with subtags would mean you'd be able to, using Joe's example from the Granularity section of the second blog post, define a User that is composed of simple properties and larger properties. Being able to define things to this level means Transfer would be an "all-the-way" sort of solution, not a partial solution for most things you need to do. I have to admit I'm utterly, totally psyched about the idea, especially with Transfer promising to generate DDL to create the DB from the model and inheritance mapping. To see Transfer become something that solves so many obvious needs, fully implemented and roaring to go, is something that I find exciting on so many levels. Laterz, J On Nov 19, 2008, at 3:03 PM, Elliott Sprehn wrote: > > What worries me the most about about this idea is that it utterly > breaks the insides of Transfer on a global scale. Essentially the > entire public API that it provides won't work. That is, readByProperty > () , readByPropertyMap(), TQL, saving, deleting, relationships... > won't work. And it won't just fail silently, Transfer will throw nasty > exceptions from the database. ... --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
