Jared, Thank you for your response... I think I will go ahead with the upgrade... it will just take a little bit of time...
Again thank you. On Oct 27, 5:05 pm, Jared Rypka-Hauer <[EMAIL PROTECTED]> wrote: > I would strongly recommend that you do the upgrade, but it's may not > be a trivial change for you, since Transfer has a particular API and > a fairly rigid notion of database design. That said, it's flexible > enough to cover most situations, just not all. One of people's > biggest complaints is that Transfer doesn't have any support for one- > to-one relationships, which seems to be a problem for some folks. And > one of the nice things about Transfer is the fact that by using > Decorators you can mirror your existing API so you don't have to > change so much application code from the get-go. > > And there are performance questions, especially if you're not on CF8, > if you have many-to-many or one-to-many relationships with LOTS of > related records. There can be a performance issue with pulling down > 300 instances of the same object to reflect all the rows in the > joined table. > > While Transfer is fantastic, and it does cover a large percentage of > users, it's not a magic bullet and you need to get to know a bit > about it and think about how it will work for or against you in your > particular application. > > J > > On Oct 27, 2008, at 12:30 PM, Jorge Loyo wrote: > > > > > thank you peter, > > > Actually, the use of transfer would have eliminated the necessity of > > creating about 159 CFCs... As you can imagine, the application load > > time is pretty long. I may have some time soon to upgrade the app and > > I want to see if including Transfer would be something I do. > > > On Oct 27, 12:57 pm, Peter Bell <[EMAIL PROTECTED]> wrote: > >> Just to jump in, firstly, for most cases, who cares? It'll work well > >> enough and pay for itself in saved dev time (i.e. "what Jared said"). > > >> But guess what. Like anything else, your mileage may vary. If you use > >> SP's or have unique edge case requirements, Transfer might end up > >> being dog slow compared to hand optimized prepared statements. > >> Probably quick and easy enough just to build it in transfer and then > >> add custom sql if you profile the running app and find specific > >> queries are causing you problems. > > >> Best Wishes, > >> Peter > > >> On Oct 27, 2008, at 11:49 PM, Jared Rypka-Hauer wrote: > > >>> Unless you're going to roll your own in-memory caching system, > >>> Transfer's going to bean a roll-your-own persistence tier any day. > > >>> To be honest, I haven't really looked at it just because the caching > >>> layer and the time saved in development beat the crap out of > >>> anything > >>> I could do anyway. > > >>> J > > >>> On Oct 27, 2008, at 11:47 AM, Jorge Loyo wrote: > > >>>> What is the difference in performance between having my own DAOs, > >>>> Gateways (with joins) and Beans and having transfer handle that > >>>> part > >>>> of my application?? > > >>>> Has anyone done any performance test that I could look into?? > > >>>> Thank you! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
