On 12/28/05 1:36 AM, Daniel Pittman wrote: > Reloading 5 from the database causes the test to pass, leading me to > conclude that the 'many to many' relationship must be cached somewhere. > > Is this correct, or is there something more complex going on? I don't > think there is, as I checked the database manually and the linkage was > surely there in the table.
All relationship and foreign key methods follow a similar set of rules. "If you don't have this info, go get it from the database. Otherwise, return what you got the last time you visited the database." Literally, an object "has" sub-objects. It doesn't just fetch them, return them to a caller, and then forget about them. It stores them within itself after gettingthem from the database, if necessary. A product "has" many prices, not "a product can get many prices" :) If you think about it, this is how load() and save() and all the column accessors work as well. All of these things, and RDBO objects in general, are not designed as a means to temporarily pull some data from the database in a procedural style. They're meant to provide a parallel, mutable representation that can be examined and modified on the Perl side and then saved back as needed. So the behavior you're seeing is correct, and it's not really "caching" IMO. If you've still got an RDBO object around (either a "main" object or a sub-object), then you've still got whatever data it last loaded. If you want to discard the data, either discard the object or re-load() it from the database. There are also ways to explicitly discard any kind of data, whether it's main object data (simply re-load()) or sub-objects (set to undef using the get/set method to cause the data to be re-fetched from the db on the next access.) RDBO::Cached actually keeps the data around even after you've discarded the original object entirely. The next time you load() the same row (i.e., row with the same primary key or unique key) even from a brand new object, you really just get back the same object load()ed earlier, and the database is not visited at all. That's caching :) -John ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object