On 12/18/05 1:53 PM, Svilen Ivanov wrote: > 2005/12/18, John Siracusa wrote: > [..snip..] >>> An alternative approach is to define new layer of classes on top of >>> for e.g. R:D:O::Metadata::Column::Varchar/Char/Text where to perform >>> the UTF decoding and then to change the type-to-class mapping in >>> R:D:O::Metadata. All my derived classes will use the new meta data >>> object and they will have Unicode support. >> >> That approach will have the best performance, but it's also the most work. > > You are right about performance penalty in trigger approach but I saw > a benefit of triggers after playing with the code -- the trigger is > actually executed when I access the property for the very first time. > This may be beneficial if I work with many object instances and I > don't access all the UTF8 properties thus minimizing the UTF decoding > 'on-demand'. Another cool thing is that R:D:O doesn't execute the > trigger on the next access.
That's true of the "built-in" inflate/deflate mechanisms in the column methods as well (for examples, see the timestamp or datetime columns). Any "built-in" encoding features would also be implemented this way. > However it is mastery to me why both automations don't work using > auto_initalize in my R:D:O object? It works fine when I manually > specify the columns/keys/relations (or copy/pasting the output of > perl_class_definition in the module). Any ideas? What version of RDBO are you using? This sounds like I bug that I fixed a few versions ago, but maybe it's back (or maybe I didn't fix it completely). If you can send me a small, self-contained test case that fails on the latest RDBO (0.58 right now) I'll be sure to fix it in the next release. >> Were you to do it on your own, the best approach would be to make your own >> trivial subclasses of the column classes, then point those column classes at >> your own custom method maker classes. Finally, make your own trivial >> metadata object subclass and map the appropriate column types to your new >> column classes. > > I'm not sure I get this right. I do understand that I need custom meta > class in order to add my own mapping type->class. I'll create > subclasses of text/varchar classes. The mapping reuses existing > non-text classes in RDBO and uses my own text-classes. I don't > understand when method maker enters the game. A sample code would be > appreciated (or just ignore me :) The chain of delegation for making column methods goes something like this. Column type name -> column type to column class map -> method type name -> method maker class name and method type -> make methods So, for example: 1. Given column type "varchar" 2. Consult mapping table in metadata object to find the column class for "varchar." The default is Rose::DB::Object::Metadata::Column::Varchar. 3. When it comes time to make methods for this column, iterate over the method types to be created (just one "get_set" method by default) and for each method type, look up the method maker class name and method type. The default is the "varchar" method type in the Rose::DB::Object::MakeMethods::Generic method maker class. 4. Make the method by calling the method maker. Further summarized: "varchar" -> Rose::DB::Object::Metadata::Column::Varchar -> "get_set" -> Rose::DB::Object::MakeMethods::Generic, varchar() Really, a column object is free to do whatever it wants in response to a $column->make_methods() call. It doesn't have to have a configurable mapping of method type names to method maker classes. All of the default columns do, but that's a "protected" API: http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object/Metadata/Colum n.pm#PROTECTED_API Anyway, that's kind of an aside. The mapping from column type names to column classes is a public API that every metadata object has to support. I just wanted to point out that the latter half of the delegation chain is optional. > The described new features above fit perfectly with my needs! However, > I'm not sure they should be in core RDBO distro since the whole UTF8 > adventure roots in the lack of UTF8 support in DBD::mysql. I think > they should be in separate CPAN distro managing with UTF8 > incompatibilities. > > BTW, does someone has similar problems with Postgre/SQLite? Encoding is a bit of a hassle everywhere. Even when the DBD seems to do the right thing, its definition of "right" doesn't always agree with everyone. I'd like RDBO to be able to handle most common needs. Being in the core doesn't mean it'd be used by default, just that it's available upon request. It wouldn't affect anyone who doesn't explicitly ask to use it. >> Anyone have any suggestions for better approaches to this problem? Is there >> an even more generic way to handle encoding/decoding? Should these checks >> and operations be done on load only or on set as well? > > I lean toward the trigger approach done on inflate because (as stated above): > (a) it is execute on demand > (b) converts any broken octets which aren't supposed to be in a > full-blown UTF8 app. As I said before, (a) will be true of the built-in solution as well. I'm inclined to make the built-in solution do (b) as well, just to be safe. -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
