if the dynamic changes in the entities are only by adding/removing scalar properties that have nothing to do with associations in the domain model, you could represent it a bit differently like with a generic key-value table, were your "dynamic entities" won't be dynamic anymore but will have a collection of key-value entries, representing the dynamically mutable properties of each of them.
On Tue, Aug 31, 2010 at 3:12 PM, Jason Meckley <[email protected]>wrote: > yes, you would need to ensure the current transactions are complete > before disposing of the session factory. > > The "strange" part is not altering the configuration at runtime > (although this too is high suspect). It would be strange to attempt to > alter the hbm files at run time. the hbm files are design time > components. once the system is running you don't change the hbm > mappings. similar to how you wouldn't change the templates of your > view engine (in windows forms) at runtime. > > if you are altering the configuration at runtime during the > application start there can be value there with minimal pain because > the session factory is still only built once. But if you are looking > for a system that will alter the domain/database on the fly anytime a > user says "create a new property/class" then you are going to have > problems that a majority of applications do not experience. > > Not only is there the issue of altering the domain, there is also the > issue of altering the database. do you apply validation, FK/PK > constraints, indexing etc. When i have read about runtime > configuration changes they are client specific and happen when the > application starts. there is still only a single factory built once. > the "dynamic" nature of the domain is handled by programmers via code, > not a UI that allows users to alter the configuration. > > put simply: the session factory is not meant to change after it's > created. the configuration object is meant to be configured once and > then build the session factory. while you *could* alter the > configuration and rebuild the session factory during run-time, there > are a number of other problems this would introduce. a few are already > mentioned in this thread. > > if the domain requires this level of fluidity (is that a word?) then a > compiled language and relational database would hinder that. a dynamic > language and a document would make much more sense. > > On Aug 31, 12:20 am, harshil hameed <[email protected]> wrote: > > if we go with rebuild session factory , > > like in web applications, wil effect the all current running transaction > > naaa, > > > > how NH can help us to manage this situation(altering the entity mappings > at > > run time). > > > > I don't think so Its a strange req.(//many application need dynamic > > mapping), > > > > On Tue, Aug 31, 2010 at 1:15 AM, Jason Meckley <[email protected] > >wrote: > > > > > you have 2 different issues you're dealing with that are independent > > > of one another. > > > > > 1. 2nd level cache. NH uses this to cache entities and queries across > > > multiple sessions. the cache is available while the session factory > > > exists. the session factory controls 2nd level cache. you are not > > > meant to access the cache directly. NH takes care of this for you. > > > it's only designed for use by the factory/session for entities. > > > nothing else. > > > > > 2. altering the entity mappings at runtime. hbm's are just 1 option to > > > setup the NHibernate.Cfg.Configuration object to build a session > > > factory. once the hbms are loaded you can alter the mappings within > > > the configuration. if you want to alter the entities at runtime you > > > would do so through the configuration object. Make it a singleton and > > > keep it around for the life of the application, just like the session > > > factory. any time you alter the configuration you will need to dispose > > > of the current session factory build a new one from the configuration > > > object. session factory is an immutable object, you cannot updated, > > > only dispose and build. > > > > > since 2nd level caching is controlled by the session factory; > > > disposing of the session factory will "reset" the 2nd level cache. > > > > > On Aug 30, 3:16 pm, nadav s <[email protected]> wrote: > > > > there's a use case where you have multiple session factories that > were > > > > configured using different mappings? > > > > if so, you'll have to cache it yourself, although it sounds like this > > > > scenario isn't possible because you're changing mappings at runtime > (you > > > > should know that you could change the mappings using the hbm classes > of > > > the > > > > configuration somehow, never done it, but changing the actual xml > files > > > > sounds really strange). > > > > > > if you have only one session factory at every given moment, then you > can > > > use > > > > a singleton. > > > > > > On Mon, Aug 30, 2010 at 8:45 PM, Krishna Jetti < > [email protected] > > > >wrote: > > > > > > > Hi Jason, > > > > > > > Here is my case at an conceptual level. All our entities can be > > > > > extended dynamically based on metadata, we are using > dynamic-component > > > > > for this modelling. At run-time if we change or add metadata for a > > > > > domain entity, we will rebuild the session factory, from the > > > > > configuration after we have change the .hbm.xml file for those > > > > > entities to add or update dynamic-component elements. > > > > > > > Now, if I enable the 2nd level cache, I can store the metadata > > > > > entity so NH will get it from its cache rather than hitting the > > > > > database everytime. But I also want to store the session factory as > > > > > well so that I don't have to re-configure our .hbm.xml files to > build > > > > > the session factory. > > > > > > > Does it make sense ? > > > > > > > Thanks > > > > > > > On Aug 30, 12:45 pm, Jason Meckley <[email protected]> wrote: > > > > > > Krishna, i think you're confused about how the session factory, > > > > > > session and 2nd level cache work together. > > > > > > > > the session factory is the source of everything in NH. It's > created > > > > > > from the configuration. the session factory should be a singleton > > > > > > within the application and should be created when the application > > > > > > starts and disposed when he application ends. > > > > > > > > sessions are cheap and should be created whenever a new > > > "conversation"/ > > > > > > unit of work/business context is required. the common scenarios > are: > > > > > > web > http request > > > > > > message bus > thread > > > > > > rich client > form > > > > > > > > 2nd level cache allows you to store entities between sessions to > > > > > > bypass the database call. the cache is stored in the session > factory > > > > > > itself and exists as long as the session factory is around. > > > > > > > > there is no reason to cache the session factory. if you want to > > > > > > decrease the time required to build the session factory you can > > > > > > serialize the configuration, but other than that you don't "save" > the > > > > > > session factory. > > > > > > > > On Aug 30, 11:53 am, Diego Mijelshon <[email protected]> > wrote: > > > > > > > > > That would be like storing a backpack in a pocket of the same > > > backpack. > > > > > > > You should use a singleton for your sessionfactory, not a > cache. > > > > > > > > > Diego > > > > > > > > > On Mon, Aug 30, 2010 at 12:22, Krishna Jetti < > > > [email protected] > > > > > >wrote: > > > > > > > > > > Not exactly.....I am looking to actually store in the session > > > factory > > > > > > > > in the cache. So that when ever there is a request to open > the > > > > > > > > session, I read the session factory from the cache and open a > > > session > > > > > > > > for it. > > > > > > > > > > What I am trying to figure out is...do we have to follow > > > conventional > > > > > > > > caching techniques or is there anything in the NH that allows > to > > > > > cache > > > > > > > > the session factory? > > > > > > > > > > Thanks > > > > > > > > > > On Aug 27, 9:19 am, Gustavo Ringel <[email protected] > > > > > wrote: > > > > > > > > > I think this is what you are looking for: > > > > > > > > http://devlicio.us/blogs/tuna_toksoz/archive/2009/03/14/an-improvemen. > > > .. > > > > > > > > > > > On Fri, Aug 27, 2010 at 4:14 PM, Krishna Jetti < > > > > > [email protected] > > > > > > > > >wrote: > > > > > > > > > > > > Hello All, > > > > > > > > > > > > Is it possible to cache the session factory using any > of > > > the > > > > > > > > > > available cache providers for NH2.1.2. I understand that > any > > > > > entities > > > > > > > > > > related to session factory can be cached but is there a > way > > > to > > > > > > > > > > configure NH to cache the session factory it self > > > > > > > > > > > > Thanks > > > > > > > > > > > > -- > > > > > > > > > > You received this message because you are subscribed to > the > > > > > Google > > > > > > > > Groups > > > > > > > > > > "nhusers" group. > > > > > > > > > > To post to this group, send email to > > > [email protected]. > > > > > > > > > > To unsubscribe from this group, send email to > > > > > > > > > > [email protected]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]> > > > > > <nhusers%[email protected]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]> > > > > > > > > > <nhusers%[email protected]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]> > > > > > <nhusers%[email protected]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]> > > > > > > > > > > > > > > > > > > <nhusers%[email protected]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]> > > > > > <nhusers%[email protected]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]> > > > > > > > > > <nhusers%252bunsubscr...@googlegroups.com> > > > > > > > > > > > > > > > > > > > . > > > > > > > > > > For more options, visit this group at > > > > > > > > > > > http://groups.google.com/group/nhusers?hl=en.-Hidequotedtext- > > > > > > > > > > > - Show quoted text - > > > > > > > > > > -- > > > > > > > > You received this message because you are subscribed to the > > > Google > > > > > Groups > > > > > > > > "nhusers" group. > > > > > > > > To post to this group, send email to > [email protected]. > > > > > > > > To unsubscribe from this group, send email to > > > > > > > > [email protected]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]> > > > > > <nhusers%[email protected]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]> > > > > > > > > > <nhusers%[email protected]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]> > > > > > <nhusers%[email protected]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]> > > > > > > > > > > > > > > > > > > . > > > > > > > > For more options, visit this group at > > > > > > > >http://groups.google.com/group/nhusers?hl=en.-Hidequoted text > - > > > > > > > > - Show quoted text - > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > Groups > > > > > "nhusers" group. > > > > > To post to this group, send email to [email protected]. > > > > > To unsubscribe from this group, send email to > > > > > [email protected]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]> > > > > > <nhusers%[email protected]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]> > > > > > > > > > . > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/nhusers?hl=en. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "nhusers" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]> > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/nhusers?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "nhusers" 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/nhusers?hl=en.
