Hi fellow Pygristas, I want to raise an issue noticed by Marek Szuba, namely that SQLTable adapts to itemClass arguments a bit too automatically. Specifically, he subclassed SQLTable with his own __getitem__ etc. methods, then initialized it with an itemClass derived from SQLRow. He discovered that SQLRow forces the SQLTable instance to change class to SQLTableNoCache (because SQLRow is a non-caching interface), causing his __getitem__ etc. methods to be ignored. Very annoying. I want to refactor to eliminate such counterintuitive behaviors.
Background: - Pygr's SQLSequence class is designed as a non-caching interface (derived from SQLRow), in order to work well with huge sequences (e.g. whole chromosomes) over a network connection to the database server. In other words, just requesting the object representing chr1 of the human genome should not block while it downloads the entire sequence of chromosome one (as the caching interface would do). Instead, it only fetches actual sequence data when the user requires it, and then only retrieves the necessary slice (instead of the whole sequence). That is very important for genome sequences. However, for Marek's application (protein sequences), a caching interface would be perfectly fine. - SQLTable is a caching interface (using TupleO as the row class); SQLTableNoCache is the non-caching interface (using SQLRow as the row class). Here is the best solution I could think of: - abandon automatic class switching in favor of explicit error messages and class names. We could provide both caching and non-caching versions of SQLSequence). If you tried to supply a non-caching itemClass to a caching database class, you'd get a clear error message telling you this will not work, and what you must do instead. What do you think? Other suggestions? Marek, do you think this would be an improvement? -- Chris -- You received this message because you are subscribed to the Google Groups "pygr-dev" group. To post to this group, send email to pygr-...@googlegroups.com. To unsubscribe from this group, send email to pygr-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pygr-dev?hl=en.
