The datacontext lifetime is too short for an useful number of cache hit. So I'm planning to make it static. Being possible a different mapping in the same AppDomain (which I don't yet know), we would need to "localize" the cache with a mapping source identifier key.
That said... I'll try! :-D Giacomo On Mon, Apr 27, 2009 at 8:21 PM, Jonathan Pryor <[email protected]> wrote: > On Mon, 2009-04-27 at 13:03 +0200, Giacomo Tesio wrote: > > Should we be able to handle different mappings for the same AppDomain on > the SAME Type? > > Glib answer: write a test and see what .NET does. Then do the same thing. > > It seem to me a quite rare situation in which the same entities are mapped > differently on different DataContext. > > Rare? Yes. But it also seems that it should be possible, given that you > can provide a MappingSource to the DataContext constructor, so a custom > MappingSource could be provided to do different things in different > scenarios... > > I ask becouse I'm plannig a static cache for DataMapper and IdentityReader. > > If we should handle such a use, it would be a little slower. > > Does it really need to be static? Or should it instead be tied to the > DataContext or DataMapper? > > - Jon > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" 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/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
