views:

201

answers:

3

Hi,

I´m using Nhibernate 2.1.2.4000 GA with Nhibernate.Linq 1.0 and latest version of FluentNhibernate downloaded from master on github.

Im doing some tests and whenever I try to delete a entity retrieved by a linq query i´m getting this error:

No persister for: NHibernate.Linq.Query`1[[Employees.Core.Entities.Employee, Employees.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]]

All other operations (insert, update and select) looks fine;

My Entity class:

    public class Employee
    {
        public Employee()
        {
        }

        public virtual Int32 Id { get; private set; }
        public virtual String Name { get; set; }    

        public virtual String SayHello()
        {
            return String.Format("'Hello World!', said {0}.", Name);
        }
    }

Mapping class:

    public class EmployeeMap : ClassMap
    {
        public EmployeeMap()
        {
            Id(x => x.Id);
            Map(x => x.Name)
                .Not.Nullable()
                .Length(50);
        }
    }

Configuration:

            Assembly mappingsAssemly = Assembly.GetExecutingAssembly();

            return Fluently.Configure()
                .Database(
                    MsSqlConfiguration.MsSql2008
                        .ConnectionString(connectionString)
                        .ProxyFactoryFactory(typeof(ProxyFactoryFactory))
                        .ShowSql())                            
                .Mappings(
                    m => m.FluentMappings.AddFromAssembly(mappingsAssemly))
                .BuildSessionFactory();

And the code that does not work:

        public void RemoveAll()
        {
            var q = from employee in _session.Linq()
                    select employee;

            foreach (var employee in q.ToList())
            {
                _session.Delete(q);
            }
        }

Any thoughts?

Thanks!

A: 

It may just be a bug in the Linq provider. You may want to try to reproduce the problem against the latest NHibernate trunk which includes a new/different Linq provider. Alternatively, if you (successfully) remove Fluent NHibernate from the equation, you can probably (relatively easily) submit a test case / bug report against the Linq provider.

Michael Maddox
+1  A: 

Are you certain the assembly you're supplying to FNH (Assembly.GetExecutingAssembly()) is actually the one containing your mappings?

Modify your Mappings call to include the ExportTo method, which'll export any mappings FNH finds to a specified folder; check out the contents of that folder and see if all the mappings are in there. If they are, then chances are it's not a FNH issue and might be a problem with the Linq provider (as Michael said).

Mappings(
  m => m.FluentMappings
          .AddFromAssembly(mappingsAssemly)
          .ExportTo(@"C:\"));

Another thing you can check is the NHibernate Configuration instance that NH is actually using. To do that, use BuildConfiguration instead of BuildSessionFactory and inspect the result; there's a ClassMappings collection (or some variation of that), which should contain all the mapped entities.

If that looks fine, then try creating your query using the Criteria API or HQL instead, see if that fixes your problem (and in that case it's almost certain to be the linq provider).

James Gregory
+1 This would make a pretty great generalized troubleshooting wiki page for FluentNH, if it isn't already!
Michael Maddox
+1  A: 

We all missed it!

Sorry guys and thanks for all your help but I just figured.

If you pay attention to the RemoveAll() method you will see that I´m trying to delete the "q" object which is not an entity, but a IQueriable instead of passing "employee". It was lack of attention.

The right code would be:

        public void RemoveAll()
        {
            var q = from employee in _session.Linq()
                    select employee;

            var p = q.ToList();

            foreach (var employee in p)
            {
                _session.Delete(employee);
            }
        }
tucaz
Very nice you posted your answer, so it melts down to NH miss-use ...
jalchr