[transfer-dev] Re: Stack Overflow Relationships?
On Jul 1, 10:40 pm, Elliott Sprehn espr...@gmail.com wrote: I updated to the Trunk version and the errors have seemed to go away. I'm going to load test it and low mem test it later this week and see if it holds up. I'm interested in your findings - I'm reasonably sure there is a mem leak issue in the trunk version of Transfer. The issue I've been struggling with on another mailing list look like they are Transfer related. I've rolled back to 1.1 and my unit test shows no leaky objects. Mark has a heap of mine to look at so I'm sure we'll get confirmation one way or the other... my box was running out of heap in as little as 24 hours so keep an eye on it. Brian --~--~-~--~~~---~--~~ 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 transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~--~~~~--~~--~--~---
[transfer-dev] Re: Railo 3.0 and Transfer ORM
I have transfer working on 3.1 perfectly.
On Jul 7, 7:12 pm, Shawn shawn.grig...@gmail.com wrote:
Bump?
On Jun 12, 7:33 pm, Mark Mandel mark.man...@gmail.com wrote:
Luis - can you be more specific than that?
Mark
On Sat, Jun 13, 2009 at 8:06 AM, Luis Majano lmaj...@gmail.com 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 jamiek...@gmail.com 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 shawn.grig...@gmail.com wrote:
Patch? Oh yes, please! :D
Glad to see you guys are working on this.
On May 24, 8:25 pm, Mark Mandel mark.man...@gmail.com 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
kevanstann...@gmail.comwrote:
There was in good discussion on the array pass by value/reference
on this a
while back:
http://www.mail-archive.com/cfc...@googlegroups.com/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 sipac...@gmail.com
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 which
to leave off for performance, then selling yourself based on
performance. If
Railo fully implements the ColdFusion spec, without requiring
non-standard
CFML attributes, compiler options and the like, then I'll be
impressed.
DW
--
E: mark.man...@gmail.com
W:www.compoundtheory.com
--
E: mark.man...@gmail.com
W:www.compoundtheory.com
--~--~-~--~~~---~--~~
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 transfer-dev@googlegroups.com
To unsubscribe from this group, send email to
transfer-dev-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/transfer-dev?hl=en
-~--~~~~--~~--~--~---
[transfer-dev] Re: simple transaction failing
Any thoughts on this? I can repeat this behavior under multiple configurations. On Jul 3, 8:09 pm, whostheJBoss dotfus...@changethings.org wrote: Sorry, here: http://www.pastey.net/117046 On Jul 3, 6:21 pm, Mark Mandel mark.man...@gmail.com wrote: I tried accessing the link.. it's timing out. I will try it again later. Mark On Fri, Jul 3, 2009 at 7:59 PM, whostheJBoss dotfus...@changethings.orgwrote: Ok Mark, I've made a detailed, clear and rich example for you. I didn't want to lose formatting, so I posted it here: http://www.oneclickpost.com/post/2OJ7dD0xtN/ This explains the exact behavior I am seeing and my configuration attempts that are producing it. If I made any typos, I apologize, you should be able to get the gist of what I'm doing though. I had gone to the trouble of writing a separate interceptor that would use execute() from Transfer's transaction to execute the handler method, but I saw the same results as I saw in the post I've just linked to. I also used this interceptor to apply AOP advice, but again, saw the same behavior that the post describes. Something about advising handler methods or executing them within a transaction with execute() is funky. On Jul 2, 2:30 pm, Mark Mandel mark.man...@gmail.com wrote: The code for AOP transactions would be exactly the same for a ColdBox handler as it would be for any other CFC, it's just a CFC. Can you send me a reproducible test case, with the DB you are using? Mark On Fri, Jul 3, 2009 at 3:36 AM, whostheJBoss dotfus...@changethings.org wrote: Oh, and this behavior is on both CF8 and Railo. I have tested for 10 hours, worked with multiple people on this and I am certain this is what is happening. On Jul 2, 10:10 am, whostheJBoss dotfus...@changethings.org wrote: Ok, so I have worked with Micha to resolve this and it looks like this issue is taken care of. I can now successfully advise my beans such as service layers, etc. So, AOP now works on Railo with Transfer when doing this. My issue (which has been the issue all along) is still that I can't advise an entire handler method in ColdBox. My scenario is that I have multiple service layer calls inside my handler and I want the ENTIRE handler method wrapped in a transaction so in case any of the service layer calls fail they will all be rolled back. I have applied the advice using this: cfset instance.TransferTransaction.advise(this,createUser, true) In my onDIComplete method of the handler and I see the trace that advice has been weaved for createUser, but the transaction simply doesn't work. When I run multiple Transfer actions where one of them is set up to fail, the others that were called first are not rolled back, even though they are all wrapped in the advice since they are all in the handler method and the method has been advised. Like I said, I see the trace that the advice has been applied to the method, but for whatever reason it doesn't do anything. I have also tried using this: cfset transaction.execute(this, createUser, arguments) Inside of a proxy method on my handler (doCreateUser). So, when I call doCreateUser() it executes createUser fine, I see database inserts and it works. However, if one of the inserts inside createUser() is set up to fail (I call it with bad data from a form, string where it should be a number), the others are not rolled back even though the entire method was called using the execute method of the transaction. So, my issue is that I need to be able to advise an entire handler method in ColdBox with Transfer, but when I try this with multiple methods, it doesn't causes any errors, but it doesn't actually advise the method with a transaction. On Jul 2, 1:22 am, Mark Mandel mark.man...@gmail.com wrote: aha, there you go! :) Mark On Thu, Jul 2, 2009 at 6:13 PM, whostheJBoss dotfus...@changethings.orgwrote: From Micha: this was a failure (only in version 3.1.0.015 to 3.1.019) we have already fixed, please update to newest release 3.1.0.020 on dev.railo.ch or wait for release coming today/tomorrow on www. Go figure! On Jul 2, 12:53 am, whostheJBoss dotfus...@changethings.org wrote: I was just coming here to update this thread... I posted this to Railo's group: http://groups.google.com/group/railo/browse_thread/thread/a34c465edcd. .. It seems that Railo is failing to rollback, not Transfer. On Jul 2, 12:38 am, Mark Mandel mark.man...@gmail.com wrote: Does Railo not rollback transactions when an error is thrown from the code?
[transfer-dev] Re: simple transaction failing
Actually, thanks for chasing this up. Fun question for you then - When you are using transaction.execute() (or even the AOP) within the handler, and you intentionally throw an error to try and rollback the Transaction, do you see any of the Transfer Transaction elements in the tag context? I'm wondering of Luis is doing some method trickery in CB with his handlers. Mark On Wed, Jul 8, 2009 at 1:36 PM, whostheJBoss dotfus...@changethings.orgwrote: Any thoughts on this? I can repeat this behavior under multiple configurations. On Jul 3, 8:09 pm, whostheJBoss dotfus...@changethings.org wrote: Sorry, here: http://www.pastey.net/117046 On Jul 3, 6:21 pm, Mark Mandel mark.man...@gmail.com wrote: I tried accessing the link.. it's timing out. I will try it again later. Mark On Fri, Jul 3, 2009 at 7:59 PM, whostheJBoss dotfus...@changethings.orgwrote: Ok Mark, I've made a detailed, clear and rich example for you. I didn't want to lose formatting, so I posted it here: http://www.oneclickpost.com/post/2OJ7dD0xtN/ This explains the exact behavior I am seeing and my configuration attempts that are producing it. If I made any typos, I apologize, you should be able to get the gist of what I'm doing though. I had gone to the trouble of writing a separate interceptor that would use execute() from Transfer's transaction to execute the handler method, but I saw the same results as I saw in the post I've just linked to. I also used this interceptor to apply AOP advice, but again, saw the same behavior that the post describes. Something about advising handler methods or executing them within a transaction with execute() is funky. On Jul 2, 2:30 pm, Mark Mandel mark.man...@gmail.com wrote: The code for AOP transactions would be exactly the same for a ColdBox handler as it would be for any other CFC, it's just a CFC. Can you send me a reproducible test case, with the DB you are using? Mark On Fri, Jul 3, 2009 at 3:36 AM, whostheJBoss dotfus...@changethings.org wrote: Oh, and this behavior is on both CF8 and Railo. I have tested for 10 hours, worked with multiple people on this and I am certain this is what is happening. On Jul 2, 10:10 am, whostheJBoss dotfus...@changethings.org wrote: Ok, so I have worked with Micha to resolve this and it looks like this issue is taken care of. I can now successfully advise my beans such as service layers, etc. So, AOP now works on Railo with Transfer when doing this. My issue (which has been the issue all along) is still that I can't advise an entire handler method in ColdBox. My scenario is that I have multiple service layer calls inside my handler and I want the ENTIRE handler method wrapped in a transaction so in case any of the service layer calls fail they will all be rolled back. I have applied the advice using this: cfset instance.TransferTransaction.advise(this,createUser, true) In my onDIComplete method of the handler and I see the trace that advice has been weaved for createUser, but the transaction simply doesn't work. When I run multiple Transfer actions where one of them is set up to fail, the others that were called first are not rolled back, even though they are all wrapped in the advice since they are all in the handler method and the method has been advised. Like I said, I see the trace that the advice has been applied to the method, but for whatever reason it doesn't do anything. I have also tried using this: cfset transaction.execute(this, createUser, arguments) Inside of a proxy method on my handler (doCreateUser). So, when I call doCreateUser() it executes createUser fine, I see database inserts and it works. However, if one of the inserts inside createUser() is set up to fail (I call it with bad data from a form, string where it should be a number), the others are not rolled back even though the entire method was called using the execute method of the transaction. So, my issue is that I need to be able to advise an entire handler method in ColdBox with Transfer, but when I try this with multiple methods, it doesn't causes any errors, but it doesn't actually advise the method with a transaction. On Jul 2, 1:22 am, Mark Mandel mark.man...@gmail.com wrote: aha, there you go! :) Mark On Thu, Jul 2, 2009 at 6:13 PM, whostheJBoss dotfus...@changethings.orgwrote: From Micha: this was a failure (only in version 3.1.0.015 to 3.1.019) we have already fixed, please update to newest release 3.1.0.020 on dev.railo.ch
[transfer-dev] Re: Stack Overflow Relationships?
Sounds like I fixed one bug to introduce another... I'll see if I can set up a memory leak test to run overnight in the next few days. Mark On Wed, Jul 8, 2009 at 2:36 PM, Elliott Sprehn espr...@gmail.com wrote: On Jul 7, 1:27 pm, Brian G brian-goo...@vfive.com wrote: On Jul 1, 10:40 pm, Elliott Sprehn espr...@gmail.com wrote: I updated to the Trunk version and the errors have seemed to go away. I'm going to load test it and low mem test it later this week and see if it holds up. I'm interested in your findings - I'm reasonably sure there is a mem leak issue in the trunk version of Transfer. The issue I've been struggling with on another mailing list look like they are Transfer related. I've rolled back to 1.1 and my unit test shows no leaky objects. Mark has a heap of mine to look at so I'm sure we'll get confirmation one way or the other... my box was running out of heap in as little as 24 hours so keep an eye on it. Thanks, I'll keep an eye on that. We did run out of memory a few days ago with a Java heap space null error, and then just a day or so ago the server got super sluggish. I forced a full restart of our platform (restarts every CF app, transfer, coldspring, etc.) and it freed about 250mb of RAM and everything was normal again. I'm watching to see if this happens again. -Elliott -- E: mark.man...@gmail.com T: http://www.twitter.com/neurotic W: www.compoundtheory.com --~--~-~--~~~---~--~~ 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 transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~--~~~~--~~--~--~---
[transfer-dev] Re: listByRelationship ? or alternative?
On Jul 2, 4:08 pm, John Watson wizpu...@gmail.com wrote: (Simplified) I have: object name=invoice table=tblInvoices id name=invoiceId type=numeric / property name=invoiceDate type=date / /object object name=invoiceItem table=tblInvoiceItems id name=invoiceItemId type=numeric / property name=itemDesc type=string / property name=itemCost type=numeric / manytoone name=invoice link to=invoice column=fkInvoiceId / /manytoone property name=fkInvoiceId type=numeric ignore-insert=true ignore-update=true / /object For performance reasons I can not have a onetomany relationship in invoice (which was a solution Mark gave on a blog somewhere, sorry I do not have a link). It takes 600 seconds to insert 400 invoiceItems; that bottleneck is at transfer.save(invoiceItem). I want to be able to retrieve all invoiceItems for the invoice. right now I just do: transfer.listByProperty (invoiceItem,fdInvoiceId,invoice.getInvoiceId()) Am I approaching this from the wrong way? Is my DB design flawed? Is my object design flawed? Usually you'd want to use TQL for this or use regular SQL. The way you're doing it means you have the foreign key in there twice? That's not usually allowed, though you can hack it with the ignore-* properties. I usually expose this kind of thing through a relationship method on the objects themselves. So I'd have: invoice.listInvoiceItems() and internally that would run a TQL query: t:query name=result transfer=#getTransfer()# select * from InvoiceItem join Invoice where Invoice.invoiceId = t:queryparam value=#getId()# /t:query That gets you a fairly transparent API that doesn't require bleeding Transfer all over and means that if you have an Invoice, you always have it's related objects just one method call away. --~--~-~--~~~---~--~~ 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 transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~--~~~~--~~--~--~---
