On Sun, Jun 28, 2009 at 6:39 PM, Elliott Sprehn <[email protected]> wrote:
> > On Jun 28, 12:46 am, Mark Mandel <[email protected]> wrote: > > To turn that around though.. you could use the > > > > getDatasource().setCurrentThreadDatasource("writeDatasource"); > > > > In combination with the Transfer Events to change your datasource details > > transparently. > > > > This would probably provide you with a much more flexible solution, as > you > > could start changing all sorts of details depending on what event you are > > running. > > > > Just trying to think of something that will serve if people had, I dunno, > > something weird, like 4 different DBs or something ;o) > > > > I just don't see this being useful because it's so much work. How is it 'so much work' - you simply create a new event listener for Transfer events (we could ship with a simple basic one), and everything changes transparently. > You'd > write the app, realize you needed to scale, and then have to go back > and rewrite all your code to handle the datasource changes. And it's > not just that one line, it's try catches and lots of architecture > decisions. You wouldn't have to rewrite any code, just implement an event listener. Now... if something goes wrong in a save, then that would need to be handled, and I can it being fair enough to call a datasource.reset() inside Transfer to manage that. > Your solution still doesn't prevent those cases where some action > causes a lazy load or a proxy load to hit the writing datasource > either. I agree, that is the tricky one, updates would need to ensure that they didn't lazy load data.. or know what the default datasource was... which gets a little messy, I have to admit. Not quite sure on this part. > That's especially dangerous if you change it inside Transfer > events, and so is the fact that you could leave your thread with the > wrong one. For instance before save might change it, but then if there > was a database failure after save would never fire, and you'd never > change it back. If that was managed inside Transfer to return the datasource to it's default state if something went wrong, that would be okay. > > There'd be no transparency because you'd need to be very careful of > what methods you call because any indirection in the same thread might > cause one of those loads on the wrong datasource. I'm not following you on this one. > > This needs to be handled inside Transfer. I'm not necessarily disagreeing with you on this one, but I am saying that I think we need a solution that is a bit more flexible than 'you can only have a read or write database', because that is a solution for a _single_ problem, but a generic solution that needs to be applied from a framework perspective. What I'm slowly thinking out is a configuration like: <datasource> <name>DefaultDataSource</name> </datasource> <mirrors> <datasource name="write"> <name>WriteDatasource</name> </datasource> <datasource name="reporting"> <name>ReportingDatasource</name> </datasource> </mirrors> Or something similar. And a mechanism, to be able to switch between the credentials as neccessary, which is far more flexibly than just 'read', and 'write'. Mark -- E: [email protected] T: http://www.twitter.com/neurotic W: www.compoundtheory.com --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
