Yeah, if I had to do it over again I'd probably do FNH. The initial reasoning was that since the meta-data we were mapping from was in xml and the end-result was hbm xml that we could just do the transformation via an XSLT transform. Plus this was just at the time that FNH was going through a major syntax change so I figured stick with hbm. Of course I looked at xslt for all of 5 minutes said screw it and wrote a big ol' LINQ statement to do the transform.
Hey Fabio, are you on twitter? I'm togakangaroo on there On Mon, Aug 30, 2010 at 10:50 AM, Fabio Maulo <[email protected]> wrote: > If you are creating mappings at run-time I recommend you to have a look to > FNH or ConfORM > > > On Mon, Aug 30, 2010 at 11:10 AM, George Mauer <[email protected]> wrote: > >> Finally figured it out. >> >> I had changed one of my class names and had changed it's name in the >> mapping node, but had overlooked the one-to-one relation that pointed >> to it. It is no surprise that the error was my own, the surprise is >> that it took nearly eight hours of work and this 500 line test class >> to identify it: http://codepaste.net/tryyjx Notice I had to use crazy >> stuff (Mirror is an excellent reflection helper framework that is part >> of MbUnit) to access internal methods of the Configuration object. >> Not only that, but tremendous amount of logic in the >> SessionFactoryImpl constructor is a huge problem. >> >> Lessons: This is something that would have been solved in about 2 >> seconds if the exception had contained relevant information, or if >> nhibernate had better logging in the area of building a session >> factory. >> >> I guess I'll go file a bug for this. >> >> On Aug 29, 7:08 pm, George Mauer <[email protected]> wrote: >> > We have not yet identified the need for this. Like I said, there is >> > an alternate mechanism of stored procedures that the client already >> > has in place that supply some of the data for things like grids and >> > reports. Even if we wanted to mess with that (which we initially >> > did), it has been scoped out of the project and turned down by the >> > client. This isn't exactly a CQRS solution, but it has some of the >> > same characteristics. >> > >> > I can see that the key being looked up is coming from >> > EntityType.AssociatedEntityName. Where in the world are EntityTypes >> > constructed? I can't find a reference to "new( )+EntityType" anywhere >> > in the source. >> > >> > Also, is there some logging that I should be able to turn on for >> > this? I haven't seen any relevant logging code while looking through >> > the stacktrace. >> > >> > On Aug 29, 6:54 pm, Fabio Maulo <[email protected]> wrote: >> > >> > >> > >> > > For the dynamic part, doyou need search capability? >> > > Can, the user, do a search for the additional property added at >> > > run-time or it is only needed in CRUD where the entity is uploaded by >> > > ID ? >> > >> > > -- >> > > Fabio Maulo >> > >> > > El 29/08/2010, a las 18:33, George Mauer <[email protected]> escribió: >> > >> > > > We've got plenty of tests around it and it works quite well and has >> > > > worked quite well for months given our requirements. My #1 concern >> is >> > > > how to figure out whats going on with this exception so that I can >> > > > finish implementing this feature. >> > >> > > > But an explanation is in order: >> > >> > > > We have a legacy requirement that certain properties on certain >> > > > entities are defined in meta-data (stored in xml) and can be added >> or >> > > > remobved by the user during run-time. We are also locked into an >> > > > implementation where adding a property will actually issue an ALTER >> > > > TABLE command to add properties to tables. We are also locked in >> (and >> > > > this has been debated plenty) to having to do this adjustment during >> > > > runtime, not in a separate "adjust meta-data" utility. I know, not >> > > > good design but like I said, locked in. >> > >> > > > The good news: This happens very infrequently. There is a flurry of >> > > > activity when the application is first deployed and then settles >> down >> > > > to a very rare occurrence. As such, the performance hit from >> > > > reconfiguring the SessionFactory has been deemed acceptable. Also >> > > > they are ONLY adding properties and only from a certain well-defined >> > > > set of property types as such it is relatively straightforward to >> > > > convert their meta-data to hbm. >> > >> > > > In our solution I wrote a simple decorator for ISessionFactory that >> > > > subscribes to a DomainMetaDataEvent from our event aggregator and in >> > > > response rebuilds the hbm mappings, adds them to a new Configuration >> > > > object and rebuilds its internal SessionFactory. The ability to >> > > > expand on the entities themselves is implemented using dynamic- >> > > > component and a bit of c# 4.0 dynamic magic. >> > >> > > > Again, this is a rare occurrence and has been deemed acceptable in >> our >> > > > tests so far. We also have strict guidelines of when we use >> entities >> > > > and when we don't. For example, for pulling out bulk amounts of >> data >> > > > (like for reporting or into a grid) we interrogate the mappings >> inside >> > > > NH and use the persisters to build up our own SQL query which is >> > > > mapped by a separate process to a set of DTOs. We basically only >> use >> > > > the dynamic entities for CUD or when we are going to be working with >> a >> > > > very small set at a time. >> > >> > > > Makes sense? >> > >> > > > On Aug 29, 4:03 pm, Fabio Maulo <[email protected]> wrote: >> > > >> My mayor preocupation is this name: MutableSessionFactory >> > >> > > >> -- >> > > >> Fabio Maulo >> > >> > > >> El 29/08/2010, a las 15:03, George Mauer <[email protected]> >> escribió: >> > >> > > >> After a recent refactoring NHibernate 2.1.2.4 started throwing a >> > > >> KeyNotFoundException when the SessionFactory is being configured. >> No >> > > >> other information is supplied, not even the key that is not found. >> > >> > > >> The stacktrace is pasted below. Clearly some mapping registration >> is >> > > >> going wrong. >> > >> > > >> What exactly are my options for tracking down the error? Compiling >> NH >> > > >> from source would be a huge hassle since we use other libraries >> that >> > > >> depend on specific versions for it (such as NH.Linq). >> > >> > > >> at System.Collections.Generic.Dictionary`2.get_Item(TKey key) >> > > >> at NHibernate.Cfg.Configuration.Mapping.GetPersistentClass(String >> > > >> className) >> > > >> at NHibernate.Cfg.Configuration.Mapping.GetIdentifierType(String >> > > >> className) >> > > >> at NHibernate.Type.EntityType.GetIdentifierType(IMapping factory) >> > > >> at >> NHibernate.Type.EntityType.GetIdentifierOrUniqueKeyType(IMapping >> > > >> factory) >> > > >> at >> > > >> >> NHibernate.Persister.Entity.AbstractPropertyMapping.InitIdentifierPropertyP >> aths(String >> > > >> path, EntityType etype, String[] columns, IMapping factory) >> > > >> at >> > > >> >> NHibernate.Persister.Entity.AbstractPropertyMapping.InitPropertyPaths(Strin >> g >> > > >> path, IType type, String[] columns, String[] formulaTemplates, >> > > >> IMapping factory) >> > > >> at >> > > >> >> NHibernate.Persister.Entity.AbstractEntityPersister.InitOrdinaryPropertyPat >> hs(IMapping >> > > >> mapping) >> > > >> at >> > > >> >> NHibernate.Persister.Entity.AbstractEntityPersister.InitPropertyPaths(IMapp >> ing >> > > >> mapping) >> > > >> at >> > > >> >> NHibernate.Persister.Entity.AbstractEntityPersister.PostConstruct(IMapping >> > > >> mapping) >> > > >> at >> > > >> >> NHibernate.Persister.Entity.SingleTableEntityPersister..ctor(PersistentClas >> s >> > > >> persistentClass, ICacheConcurrencyStrategy cache, >> > > >> ISessionFactoryImplementor factory, IMapping mapping) >> > > >> at >> > > >> >> NHibernate.Persister.PersisterFactory.CreateClassPersister(PersistentClass >> > > >> model, ICacheConcurrencyStrategy cache, ISessionFactoryImplementor >> > > >> factory, IMapping cfg) >> > > >> at NHibernate.Impl.SessionFactoryImpl..ctor(Configuration cfg, >> > > >> IMapping mapping, Settings settings, EventListeners listeners) >> > > >> at NHibernate.Cfg.Configuration.BuildSessionFactory() >> > > >> at >> PCS.Data.NHibernate.MutableSessionFactory.CreateSessionFactory() >> > > >> in W:\PCS\GeorgeDev\Src\PCS\PCS.Data.NHibernate >> > > >> \MutableSessionFactory.cs:line 27 >> > >> > > >> -- >> > > >> 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 athttp:// >> 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 athttp:// >> 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. >> >> > > > -- > Fabio Maulo > > > -- > 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.
