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.

Order:
1.) Call an event that uses getTagsArray();
2.) Call an event that uses addTags(tag); to add a tag, the save works
and tag shows up
3.) Call an event again that uses addTags(tag); to add a tag, the save
does not work, tag does not show up

So, the first time I call the addTags() method after having called
getTagsArray(), anything after that won't.



On Nov 2, 3:44 pm, Mark Mandel <[email protected]> wrote:
> 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 
> <[email protected]>wrote:
>
>
>
>
>
>
>
> > 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 - getTagsIsLoaded()
>
> > After second save (save fails):
> > false - getIsDirty()
> > false - getTagsIsLoaded()
>
> > On Nov 2, 2:27 pm, Mark Mandel <[email protected]> wrote:
> > > On Tue, Nov 3, 2009 at 9:25 AM, whostheJBoss <[email protected]
> > >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 problems originally, since the objects were
> > > > still in memory after creation, so they were loading instantly on the
> > > > view page. After reinitializing my application and then trying to load
> > > > the objects, the problem is apparent. I was only testing with 5 or 10
> > > > in the beginning so the problem floated by unnoticed, so I'm glad I
> > > > switch to a query anyway. Still, the original many-to-many add / get
> > > > array problem persists in the cases where I only have a few objects. I
> > > > have been using a query for those as well, but would still like it to
> > > > work through Transfer  if possible, as I would like to use some of the
> > > > objects.
>
> > > Generally speaking setting up relationships so that they have a huge
> > number
> > > of objects is a bad idea...
>
> > > > To answer your question, yes, this is only happening when the objects
> > > > are proxied. I will check the results of getIsDirty() and
> > > > getTagsIsLoaded(), but I should let you know that I have tried
> > > > running .loadTags(); before calling getTagsArray(), but the issue is
> > > > unaffected. What results should I have for those two?
>
> > > Dirty should be 'true', and isLoaded() should also be true.
>
> > > > Oh, a sort of side-note, but having run these queries via TQL to patch
> > > > the problem, I notice that they are run each time and are not cached.
> > > > I have taken to copying the generated SQL from Transfer out into a
> > > > normal <cfquery> so that I can enable caching when I need to. Is there
> > > > a way to turn on caching for TQL queries?
>
> > > There isn't a way to cache TQL results as of yet.
>
> > > Mark
>
> > > --
> > > E: [email protected]
> > > T:http://www.twitter.com/neurotic
> > > W:www.compoundtheory.com
>
> --
> E: [email protected]
> 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 [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
-~----------~----~----~----~------~----~------~--~---

Reply via email to