Okay, so the addTags() *does* work, just something is the save() is going
fubar.
(Probably has to do with cache synchronisation).
I'm ripping apart Transfer at the moment, I have an idea what it may be...
I'll have a look.
Mark
On Tue, Nov 3, 2009 at 9:12 PM, whostheJBoss wrote:
>
> 1
> 2
> 3
Excellent! Thank you! Even though I've worked around the problem, it
would be great if this worked, I've been quite curious as to why it
doesn't.
p.s. If you are ripping it apart, perhaps TQL query caching would be
possible? :)
On Nov 3, 2:31 pm, Mark Mandel wrote:
> Okay, so the addTags() *doe
1
2
3
4
5
6
7
It shows all 7 tags. However, the 6 and 7 do not stay saved. After save
() is called, they are gone again.
On Nov 2, 6:51 pm, Mark Mandel wrote:
> On Tue, Nov 3, 2009 at 12:25 PM, whostheJBoss
> wrote:
>
> > Step 3.) call event with:
> > tag1 = Transfer.get("tags.tag", 6);
> > ta
On Tue, Nov 3, 2009 at 12:25 PM, whostheJBoss wrote:
> Step 3.) call event with:
> tag1 = Transfer.get("tags.tag", 6);
> tag2 = Transfer.get("tags.tag", 7);
> post = Transfer.get("posts.post", 1);
> post.addTags(tag1);
> post.addTags(tag2);
>
What happens if you dump the object at this point?
>
Ok, I'll be more clear:
When I start, my post object has has three tags attached as many-to-
many with the following ids: 1,2,3
Before step 1:
false - isdirty
false - isloaded
Step 1.) call event with:
post = Transfer.get("posts.post", 1);
rc.tags = post.getTagsArray();
View:
Loop through rc.t
Okay, so you didn't really answer my question then, maybe I wasn't clear.
Before second save:
true - getIsDirty()
true - getTagsIsLoaded()
--> dump out the tags - are all the tags there?
--> add some more tags
--> dump it again, are the tags there?
After second save (save fails):
false - getIsDi
That's why I'm asking you :)
If I use addTags() and then save it, a dump of the object shows no new
tags.
However, if I use addTags() and then dump the object, before saving,
there are tags...
On Nov 2, 4:25 pm, Mark Mandel wrote:
> That doesn't make sense how an add/remove doesn't fire on the
That doesn't make sense how an add/remove doesn't fire on the object... even
if the data is all wonky, the add/remove should still work. the proxy()
method on the ObjectProxy always goes *somewhere* even if that somewhere
goes to an error.
Mark
On Tue, Nov 3, 2009 at 11:21 AM, whostheJBoss wrote
addTags() works the first time, when I dump getTagsArray() after the
first save, they show up.
Any add or remove after that is not reflected in the object.
On Nov 2, 4:09 pm, Mark Mandel wrote:
> So what happens between:
>
> Before second save:
> true - getIsDirty()
> true - getTagsIsLoaded()
>
So what happens between:
Before second save:
true - getIsDirty()
true - getTagsIsLoaded()
--> dump out the tags - are all the tags there? or did addTags() not work?
After second save (save fails):
false - getIsDirty()
false - getTagsIsLoaded()
What is weird is the getTagsIsLoaded() is being res
Oops, I had a slight omission in the original post (or one of those
following it, not sure at what point I came across this aspect of the
behavior), the first addTags() after calling the array works,
subsequent calls won't.
Sorry, so I meant when running the event that does the save a second
time
What is the second save? I only see one save in the original code?
Mark
On Tue, Nov 3, 2009 at 10:38 AM, whostheJBoss wrote:
>
> Before calling getTagsArray():
> false - getIsDirty()
> false - getTagsIsLoaded()
>
> After calling getTagsArray():
> true - getIsDirty()
> true - getTagsIsLoaded()
>
It was:
Before calling getTagsArray():
false - getIsDirty()
false - getTagsIsLoaded()
After calling getTagsArray():
true - getIsDirty()
true - getTagsIsLoaded()
Immediately after first save (save works):
false - getIsDirty()
true - getTagsIsLoaded()
Before second save:
true - getIsDirty()
true
Before calling getTagsArray():
false - getIsDirty()
false - getTagsIsLoaded()
After calling getTagsArray():
true - getIsDirty()
true - getTagsIsLoaded()
Immediately after first save (save works):
false - getIsDirty()
true - getTagsIsLoaded()
Before second save:
true - getIsDirty()
true - getTag
>
> So any thoughts on if isLoaded() comes back false? And still comes
> back false after calling loadTags() ?
>
I only have thoughts if it is actually doing that...
Mark
--
E: mark.man...@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com
--~--~-~--~~--
Yes, I've decided now to use the many-to-many for editing only, so
anything POST/write is going to be using addTags(), and anything GET/
read is going to be TQL / SQL. That way I never call getTagsArray()
(since there will be hundreds), but I can still use addTags() to add
them. Since the tags are
On Tue, Nov 3, 2009 at 9:25 AM, whostheJBoss wrote:
>
> Performance is horrid with that many objects. I have since switched to
> using a query for the large collections (which also fixes the original
> issue of this post). I had a 2900% increase in performance. I hadn't
> noticed the performance p
Performance is horrid with that many objects. I have since switched to
using a query for the large collections (which also fixes the original
issue of this post). I had a 2900% increase in performance. I hadn't
noticed the performance problems originally, since the objects were
still in memory aft
Somehow 'dirty' came out as 'directy'
I have no idea why... :(
Mark
On Tue, Nov 3, 2009 at 8:56 AM, Mark Mandel wrote:
> So this is still directly related to having the object as a proxy, as
> opposed to having it as a full blown object?
>
> (Just curious how the performance is of 500 objects,
So this is still directly related to having the object as a proxy, as
opposed to having it as a full blown object?
(Just curious how the performance is of 500 objects, I'd be doing that more
as a query, but I digress)
So some things to check out:
Is the object directy: #post.getIsDirty()#
Ok, I have tested this on CF8 and CF9 and I get identical behavior as
I do with Railo. If I make a call to the SOMEPARENT.getWHATEVERArray()
function, subsequent saves of many-to-many WHATEVER to SOMEPARENT do
not save. The first addWHATEVER() works, but after that they fail to
save.
In this case
The only thing I can think of is somehow the Lazy Load xIsLoaded() isn't
being set to true somehow.
On Wed, Oct 28, 2009 at 2:00 PM, whostheJBoss wrote:
>
> You seem to give me that answer a lot :)
>
> I'd say it's pretty well tested, seeing as I've tried just about
> everything you can try with
You seem to give me that answer a lot :)
I'd say it's pretty well tested, seeing as I've tried just about
everything you can try with Transfer on Railo and have repeatedly
reported any odd behavior.
So, doesn't this post count as me officially reporting odd behavior to
you?
I can't do a lot mor
The fact you are using Railo and that Transfer really isn't well tested (or
tested at all) on that platform spring to mind
Mark
On Wed, Oct 28, 2009 at 1:17 PM, whostheJBoss wrote:
>
> I hate to beat this horse, but I'm still having this issue. The
> problem is even more prevalent now. I hav
I hate to beat this horse, but I'm still having this issue. The
problem is even more prevalent now. I have many situations where I
need to first get the array of items before using them, but doing so
causes any add (or remove) of the many to many objects not to save.
Any thoughts at all on this? S
I have written a custom TQL that handles my problem and all is great,
so this is not a question I *need* the answer to, but I'm still quite
curious WHY this is happening. Any thoughts on why calling
getPostsArray() first breaks the functionality to add a tag?
On Sep 26, 7:53 am, whostheJBoss wro
I will add one more thing... the save() only fails after the call of
getPostsArray() if the post I am trying to add tags to was included in
the array that was retrieved.
So, if getPostsArray() returns posts 1 and 3, then tags added to those
two posts will not save. Tags added to post 2, which was
Ok, another update... if I set proxied="false" on:
Then it works! I can call getPostsArray() first and still add tags.
So, having the onetomany posts object on users.user proxied causes the
odd behavior. I don't think t
28 matches
Mail list logo
