Re: Documentation blues

[prev] [thread] [next] [Date index for 2005/06/21]

On Wed, 2005-06-22 at 00:29 +1000, Jacinta Richardson wrote:
> As far as I see it, there are a number of situations to consider:
> 
> 	1.  Object exists in cache but *doesn't* have the temporary column(s)
>              provided by the search filled in - edit the object and return

To do this, you have to determine which columns in the incoming data are
meant to go to TEMP columns and skip the rest.  If you'd like to provide
a patch that does this, feel free.  Please use the latest 0.999 source
that Tony posted though, rather than 0.96.  If the performance impact is
significant, it might not be such a great idea.

> I *asked* the database to perform a search for me so I obviously
> want the data the database returned.

You don't obviously want data changes that were made by other processes
to alter your in-memory objects though, outside of TEMP columns.  Thus
the need to check which ones are bound for TEMP columns.

> You could argue that its the programmer's responsibility to remember to clear 
> the cache before running such a query, but this is an extremely heavy handed 
> approach to what should be a simple problem.

There is no cache.  You will only have objects in the object index if
they are currently held by in-scope variables in your code.  If you
expect you will frequently want to re-fetch objects that you already
have, I suggest you turn off the object index.  Lots of people do it.

> Should there be hundreds of large 
> objects in the cache flushing the cache could become expensive.

The index is just a hash of weak refs.  Clearing it is not expensive.

> If you still think that patching the handling of TEMP columns is a bad idea or 
> if you have an opinion regarding the correct behaviour in a conflict situation 
> I'd love to hear your reasons.

I don't think the use of TEMP columns to hold aggregate data is a good
practice, so I'm not inclined to spend a lot of time on it when turning
off the object index works just fine.  If someone else wants to work on
a patch, go for it.

- Perrin