Re: Documentation blues

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

Perrin Harkins wrote:
> On Tue, 2005-06-21 at 22:37 +1000, Jacinta Richardson wrote:
> 
>>It's pretty clear that what is happening is that since the objects my search is 
>>turning up already exist in the global cache of objects they're not being 
>>created and thus aren't gaining this new column value.
> 
> 
> This has been discussed on the list before.  It's not hard to patch
> this, but it probably isn't a good idea, because data in objects you are
> already working with could get overwritten.
> 
> Is there a reason you are keeping those other objects in memory before
> running this query?  If you really have to keep them around, you can
> call clear_object_index() before running the query.

In my specific case, calling clear_object_index is probably acceptable.  However 
    I can think of numerous cases where this action from a distance could cause 
significant problems.

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

		* Nice, easy, probably solves 80% of the cases I can think of

	2.  Object exists in cache does have the temporary column filled in
	    but value is the same. - return object

		* Nice, easy, probably not going to happen very often...

	3.  Object exists in cache, does have the temporary column filled in but
	    with a different value.

		- Overwrite value ... could be acceptable, it is TEMPorary after
                   all

		- Croak/warn/die... throw exception regarding conflict

		- Do nothing (current approach).

Of the three options above in the conflict scenario the last one is the least 
useful to me.  I *asked* the database to perform a search for me so I obviously
want the data the database returned.  Nevertheless, if we implemented the first 
check and had an "otherwise do nothing" approach then we'd at least be doing 
something useful with this kind of search.  Personally I'd go with the 
"overwrite the TEMPorary column value with that from the new search" option. 
This makes intuitive sense in most cases I can think of.

For example, take the CDs example.  Let's assume we have a data entry system to 
add CDs and other related information to the database.  Included in our options 
are list options.  These may include the artist with the most CDs, the top 10 
artists by number of CDs, the bottom 10 artists by number of CDs.  Should the 
user run such a query, add a bunch of data and then run the query again the TEMP 
data (number of CDs) ought to be updated even if the objects are currently in 
the cache.

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.  Should there be hundreds of large 
objects in the cache flushing the cache could become expensive.

Note that I'm talking *only* about TEMP columns.  If the database query returns 
other column information which doesn't match the current objects then I agree 
with the "do nothing" approach.

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.

All the best,

     Jacinta


        -- 
            ("`-''-/").___..--''"`-._          |  Jacinta Richardson         |
     `6_ 6  )   `-.  (     ).`-.__.`)  |  Perl Training Australia    |
     (_Y_.)'  ._   )  `._ `. ``-..-'   |      +61 3 9354 6001        |
   _..`--'_..-_/  /--'_.' ,'           | contact@xxxxxxxxxxxx.xxx.xx |
  (il),-''  (li),'  ((!.-'             |   www.perltraining.com.au   |