All you said, at least in this thread was "I have transfer working on 3.1 perfectly." I have asked questions on this subject here and on the Railo forums. There's always someone who chimes in with some variation of, "You're having problems running Transfer on Railo? My setup is running fine." So excuse me. I inferred from your single sentence contribution to this thread and the one which preceded it (which *I* started) that you were being dismissive by merely saying a variation of what seemed, to me, "Works on my machine".
Sorry, I haven't read your credentials, and I an unaware of your extensive work on these forums. So no need to get all hot and bothered, either. I posted the first thread which I am aware of involving issues with Transfer ORM and Railo 3.0 (some of the same issues in 3.0 that we're having now in 3.1, btw) back in October of 2008. You can reference the post here, in case you're interested in some reading of your own: http://groups.google.com/group/transfer-dev/browse_thread/thread/95a519fb53c0f504/5e5b70250fff1abd So it's not like I haven't been contributing to discussion here, particularly on this topic, for a long time, either. I'm ass deep in a huge project and have been for months now. I put in a lot of work outside of the office researching new technologies and yes, I've even been digging into the guts of Transfer ORM in my spare time, because I'm fearing more and more that if it's going to work on both Railo and CF8/9 I'm going to end up having to do the modifications myself. So I ask for a 'bump', because obviously the best/fastest fix all around is a patch from someone with a bit more understanding of the framework than myself, and instead of any enlightening response I get your single sentence, "I've got it working". I might have overreacted a bit, thinking that this was a dismissive response on your part, but you must admit you gave me absolutely nothing to go on, either. Your latest post is full of the kind of elaboration which might have done some good. Still, the lesson for myself is to do more searching of the group, and don't expect people to provide updates in whatever thread I might have starred. Doing some searching, I see that you have been asking some questions recently about Transfer and Railo, so I share your pain. I have been asking/researching for many months now myself on these forums and others, so if I seem a bit frustrated by a seeming lack of progress in pursuing the incompatibility issues with Transfer and Railo, I assure you it's nothing personal. A good lesson for me, though, in making wrongful assumptions. Apologies, - Shawn On Jul 13, 12:48 pm, whostheJBoss <[email protected]> wrote: > I don't exactly see how YOUR comment was constructive either, but I > decided I should respond. I did think about letting it go... but that > didn't last long. > > First, take a look around these forums and you'll see that I've been > working Mark directly on a few of these issues, so he's aware of the > tweaks I had made to my transfer installation originally... he's even > commented about them. I've documented VERY well the changes I've made > and Mark has actually started writing a new feature for ignore/skip of > compositions/objects during cascadeDelete / Save based on code from I > posted to achieve this functionality. So, yes, I have "let Mark Mandel > know". > > Second, I've been contributing on here quite a bit, as well as on the > ColdBox forums directly with Mark and Luis about some of these issues, > so they are familiar with what I'm doing. The details of my > configuration are no secret. I've communicated regularly with the > Railo team, Mark and with Luis about what I've been attempting. This > PARTICULAR post was a chime in because I was making quite a few other > posts on here at the same time regarding these EXACT issues and it was > just a little update for those interested. My one comment was not > meant to be representative of my entire configuration. Not to mention > I wrote it while mobile and had intended an update with details when I > could get back to it but hadn't gotten around to that yet. > > Third, and most importantly, the version of Transfer I have working on > Railo 3.1 is UNMODIFIED. I'm using a fresh copy of Transfer with no > modification on Railo 3.1.0.022 and the same XML file works on both > Railo and CF8. I am not using every type of configuration under the > sun, but I'm using most of them and I've tested everything from proxy > objects with and without lazy loading, many to one, one to many, many > to many and just about everything else. > > I wouldn't have said anything, but you put the time and energy to come > on here and lambaste me for something, so I took the time and energy > to respond. > > I usually don't respond this way, but it's not like you came on here > to play nice. > > I'm one of the ones who got his configuration working with a lot of > changes to my XML file AND by doing some modifications to Transfer > itself to try and do some testing. In the end Transfer worked the way > I wanted without any changes to the core system. > > My primary concern in doing all of this was to get a cross-platform > solution working, which I stated many times while posting my progress, > and here you come telling me the point of using frameworks as if I > don't understand that? > > Go back to sleep and maybe you'll wake up on the right side of the bed > tomorrow. That, or do a little reading first. > > On Jul 13, 7:17 am, Shawn <[email protected]> wrote: > > > *sigh* I wish people would stop saying stuff like this. It minimizes > > the problem. It's great that after tweaking your transfer.xml settings > > you got Transfer to run perfectly. That's NOT the same thing as > > taking a transfer.xml file that works on CF8 and having it run without > > ANY modification in Railo. That doesn't mean it 'works'. It's a > > workaround for a core problem. > > > Or have you fixed your own copy of the Transfer framework? If so, > > please let Mark Mandel know so he can apply these fixes to the > > Transfer ORM framework. > > > That's the point of a framework: You abstract out all of the system- > > specific stuff so that the framework runs consistently across multiple > > environments. Just because you got Transfer working perfectly > > (congrats, by the way) it doesn't really contribute anything to the > > core compatibility issues surrounding the implementation of Transfer > > ORM on Railo. It's a variation of "Works on MY Machine". That > > doesn't mean there aren't any issues. > > > If I take my transfer.xml file that I have right now, and convert most > > of my relationships to 'lazy="true"', I can get things to run, too. > > Unfortunately, there are other parts of the code that expect some of > > these relationships to be loaded by default (hence why I didn't use > > 'lazy' when I defined them to begin with). > > > In what way was your comment useful to this discussion? You got it > > running? Great. Does that mean we should close the issue, stop > > worrying about it, because you were able to get it running? How many > > tables are represented in your transfer.xml file? Are all types of > > transfer relationships represented? (many to many, one to many, many > > to one?) Did you have to modify your existing (working) transfer.xml > > file to get it to run on Railo? Or did you develop your transfer.xml > > on Railo from the start, with the expectation that your app would only > > ever need to run on Railo? > > > So yeah, great, for those of you who managed to get Transfer running > > on Railo, after who knows how many tweaks of your transfer.xml file > > and rewriting of your code (which ran fine on CF8), congratulations. > > This thread obviously isn't directed at you. > > > On Jul 7, 10:31 pm, whostheJBoss <[email protected]> wrote: > > > > I have transfer working on 3.1 perfectly. > > > > On Jul 7, 7:12 pm, Shawn <[email protected]> wrote: > > > > > Bump? > > > > > On Jun 12, 7:33 pm, Mark Mandel <[email protected]> wrote: > > > > > > Luis - can you be more specific than that? > > > > > > Mark > > > > > > On Sat, Jun 13, 2009 at 8:06 AM, Luis Majano <[email protected]> > > > > > wrote: > > > > > > > Sorry, forgot about this. Well the patch is to add a new attribute > > > > > > to > > > > > > cfarguments called "passby=value" on all cases where recursion is > > > > > > done > > > > > > and arrays are passed. > > > > > > > On Jun 4, 5:51 pm, Jamie Krug <[email protected]> wrote: > > > > > > > +1 :) Mark or Luis: do you happen to have this patch, or maybe > > > > > > > point > > > > > > > me in the right direction? > > > > > > > > Thanks! > > > > > > > Jamie > > > > > > > > On May 26, 10:17 am, Shawn <[email protected]> wrote: > > > > > > > > > Patch? Oh yes, please! :D > > > > > > > > > Glad to see you guys are working on this. > > > > > > > > > On May 24, 8:25 pm, Mark Mandel <[email protected]> wrote: > > > > > > > > > > Luis, can you send me a patch with the appropriate place this > > > > > > workaround > > > > > > > > > needs to be placed inside Transfer? > > > > > > > > > > Mark > > > > > > > > > > On Fri, May 22, 2009 at 8:22 AM, Kevan Stannard < > > > > > > [email protected]>wrote: > > > > > > > > > > > There was in good discussion on the array pass by > > > > > > > > > > value/reference > > > > > > on this a > > > > > > > > > > while back: > > > > > > > > > >http://www.mail-archive.com/[email protected]/msg01670.html > > > > > > > > > > > Sean clarified the Adobe ColdFusion behaviour as: > > > > > > > > > > > Arrays are actually copy-on-assignment. When you pass an > > > > > > > > > > array to a > > > > > > function, it assigns the array to the argument, creating a copy. > > > > > > When you > > > > > > return an > > > > > > > > > > array from a function, it does not copy it - unless you > > > > > > > > > > assign the > > > > > > result to a variable. You can see that here: > > > > > > > > > > > <cfscript> > > > > > > > > > > a = [ 1, 2, 3, 4 ]; > > > > > > > > > > > function getA() { return a; } > > > > > > > > > > > b = getA(); // copies a so b is a separate array > > > > > > > > > > b[1] = 42; // does not change a > > > > > > > > > > > arrayAppend(getA(), 5); // no assignment - a *is* modified > > > > > > > > > > </cfscript> > > > > > > > > > > > On Railo's compatibility; I would be surprised if Railo > > > > > > > > > > changed > > > > > > this particular behaviour for performance reasons. I imagine this > > > > > > decision > > > > > > was made to implement it how it should have been done in Adobe CF. > > > > > > I read > > > > > > somewhere that BlueDragon also implements array pass-by-reference > > > > > > (not > > > > > > sure). > > > > > > > > > > > Perhaps the problem is not with Railo, perhaps Adobe should > > > > > > implement: > > > > > > > > > > <cfargument name="myArray" type="Array" passby="reference" > > > > > > > > > > /> > > > > > > > > > > > I do want all of the CFML engines to implement fundamental > > > > > > > > > > language > > > > > > behaviour in the same way, but I don't see a problem in this > > > > > > particular > > > > > > case. > > > > > > > > > > > Fortunately we have a CFML steering committee now which > > > > > > > > > > should > > > > > > hopefully maximise compatibility with CFML engines. > > > > > > > > > > > 2009/5/21 Dan Wilson <[email protected]> > > > > > > > > > > >> You knowm I am of two minds about this. The engineer in > > > > > > > > > >> me is all > > > > > > about a > > > > > > > > > >> more performant engine. I've made some design mistakes I > > > > > > > > > >> wish I > > > > > > could fix, > > > > > > > > > >> for performance, for extensibility or for the good of the > > > > > > children... > > > > > > > > > >> whatever. Mistakes happen. > > > > > > > > > > >> However, for Railo to change the way CFML works, and then > > > > > > > > > >> tout > > > > > > themselves > > > > > > > > > >> as faster and better is a little bit rich. Sure you can be > > > > > > faster/better if > > > > > > > > > >> you don't implement everything ColdFusion does. But you > > > > > > > > > >> aren't > > > > > > fully > > > > > > > > > >> competing then either, are you? > > > > > > > > > > >> Take Chris's example, the xe.formaction='whatever'. Sure > > > > > > > > > >> this is > > > > > > slower to > > > > > > > > > >> look up. Sure if I was writing an engine for pure speed > > > > > > > > > >> I'd try to > > > > > > not > > > > > > > > > >> support it, heck it affects EVERY variable lookup. > > > > > > > > > >> However, the > > > > > > standard > > > > > > > > > >> (good, bad or ugly) has been set for years and ColdFusion > > > > > > > > > >> supports > > > > > > it. For > > > > > > > > > >> Railo to not support it means they are out of compliance > > > > > > > > > >> with > > > > > > ColdFusion and > > > > > > > > > >> I would be very hesitant to use Railo on existing code for > > > > > > > > > >> that > > > > > > reason. > > > > > > > > > > >> In short, I love the idea of Railo and I love the idea of > > > > > > > > > >> a faster > > > > > > engine. > > > > > > > > > >> I don't love Cherry Picking which parts of ColdFusion to > > > > > > > > > >> support > > > > > > and > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
