TransferORM / transfer

ColdFusion ORM library created by Mark Mandel, updated by @ghidinelli
Other
5 stars 3 forks source link

Dirty data when cache is disabled #12

Closed SirRawlins closed 9 years ago

SirRawlins commented 9 years ago

HI There,

I have a one-to-many relationship between Foo and Bar, whereby Foo has many Bars.

If I update an instance of Bar, and save it. When looking at Foo.getBarArray() I am presented with the old dirty version of the Bar, before it was updated.

This only happens when caching is disabled.

Is this expected behaviour? seems a little counter intuitive getting dirt data when the cache is disabled.

ghidinelli commented 9 years ago

That definitely seems... bad. Tagging @markmandel to see if that's intended?

SirRawlins commented 9 years ago

@ghidinelli thanks Brian. It could potentially be something specific with my setup but thought I would chime in here for some advice as don't know the Transfer codebase well enough to go digging. If it helps this appears to be a problem not just on 1.3 but also on 1.1.

ghidinelli commented 9 years ago

@SirRawlins - is this inside the same request? Meaning, something like this:

bars = foo.getBarArray()

bars[1].setVal(newvalue);

transfer.save(bars[1]);

// bars[1].getVal() = old value?

If so, that seems right to me actually. You would need to call getBarArray() again which, without a cache, should fetch from the db? I've never run without cache so I don't know offhand.

SirRawlins commented 9 years ago

@ghidinelli yes inside the same request. Something like:

bar = transfer.get('bar', 1);
bar.setVal(newvalue);
transfer.save(bar);
bars = foo.getBarArray();
bar.getVal(( // New Value
bars[1].getVal() // Old Value

Thanks for coming back to me so quickly.

ghidinelli commented 9 years ago

You don't show when you get foo? If before the transfer.get(bar), then I suspect this is intended behavior when the cache is off (which is to say, saving the object doesn't update the in-memory example). I'll wait for Mark to confirm if that's the case or not.

I presume if you don't get the bar directly via transfer.get() in the first step, but rather got it through getBarArray(), then you would see the newvalue?

markmandel commented 9 years ago

(if memory serves) - no cache means exactly that, absolutely no cache.

There is no reuse of objects so every request is a brand new object, in which case, there is no interconnection on changes.

If you want a small cache, but with interconnected objects, I would suggest using a request level cache, as then it's only tied to your specific request.

ghidinelli commented 9 years ago

Thanks @markmandel, clever suggestion of the request cache. I'm going to close this as by design.

SirRawlins commented 9 years ago

Thanks for the clarification guys, I had misunderstood the no-cache setup and assumed that every single call to getBarArray() would trigger a fresh DB query for the collection.

I'll run with a request cache for now then, seems to make logical sense to me.