On 10/6/05, Uwe Voelker <[EMAIL PROTECTED]> wrote: > And it would be possible to store the blob in the future in the > filesystem and write a custom class which behaves like a RDBO class.
You could do it by making a new method type that loads from the file system on demand, but that's about it. It wouldn't be "prefetched" by the manager or anything like that. RDBO is not abstracted to that degree. If the data source is not accessed via DBI, you're out of luck. (No SMTP-backed objects, sorry ;) > Btw: As you mention "relationship" and "foreign key". Does RDBO make a > difference between "foreign key" or "one to one"/"many to one" relationship? I'll talk about it in the tutorial, but the key difference is that you should use a foreign key only when there's an actual foreign key on the table in the database using a real FOREIGN KEY constraint, etc. Foreign keys can be "one to one"or "many to one", with "many to one" being the default. Each foreign key will automatically generate a corresponding "... to one" relationship that will simply act as a proxy for the foreign key. This is documented. You should explicitly add a "... to one" relationship when the table has no foreign key (either because the db doesn't support them or for some other reason) but there is still a "... to one" relationship between the tables. In reality, right now, nothing bad will happen to you if you don't follow these guidelines and "lie" by making foreign keys in your RDBO classes when none actually exist in the database. But someday that might change :) -John ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Rose-db-object mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rose-db-object
