After NH 3.3.0GA?

[Oskar Berggren]

So what do we do now that NH 3.3.0GA is released?

There are already several interesting pull requests lined up, some of
which are new features. I propose that the next planned version will
be 3.4.0.


What about possible as yet undetected regressions in NH 3.3.0GA? Do
you think it would be a good idea to hold of merging to the master
branch for a week or so in case any important regressions pops up and
we want to do a 3.3.1? One can do this from a branch of course, but
without the assistance of the excellent build server.


/Oskar

[Fabio Maulo]

In general after a release we have some other 2 or 3 minor releases (for some reason was not the case for 3.2.0).

For vNext I'm strongly oriented to make another "big" breaking change... NH4.0.0 .NET4 with bye bye to Iesi.Collection, drop of some custom threadsafe collection to use those implemented in .NET4 ... 

NH4.1.0 drop of IDictionary for dynamic object and the usage of .NET4 dynamic , 

NH4.2.0 the usage of parallel to hydrate collections after queries.

--
Fabio Maulo

[Julian Maughan]

Another option to consider is skipping .NET 4, and going straight to 4.5? 

[Fabio Maulo]

That mean just: "wait some more months after you have waited one year".

btw,

which are the specific features of .NET4.5 you are thinking about and how they may benefit NH ? 

--
Fabio Maulo

[Ricardo Peres]

Hi!

Sorry for getting in the middle of your discussion... just wanted to ask one thing: some guys implemented strongly typed update and delete operations on top of LINQ for Entity Framework (https://github.com/loresoft/EntityFramework.Extended).

For example:

//delete all users where FirstName matches

context.Users.Delete(u => u.FirstName == "firstname");

//update all tasks with status of 1 to status of 2

context.Tasks.Update(

    t => t.StatusId == 1, 

    t2 => new Task {StatusId = 2});

//example of using an IQueryable as the filter for the update

var users = context.Users.Where(u => u.FirstName == "firstname");

context.Users.Update(users, u => new User {FirstName = "newfirstname"});

Do you think this would be something interesting for NHibernate?

Thanks,

RP

[Diego Mijelshon]

Considering NH already has HQL updates, it's less of an issue... It's a nice feature nonetheless.

It can probably be implemented without breaking changes, so it's just a matter of starting it.
 
    Diego

[Diego Mijelshon]

I see a couple ways to benefit from .NET 4.5:

- Targeting the Portable Class Library

- Taking advantage of (and exposing) async methods

Both require considerable effort.

The latter can result in interesting improvements. Consider:

  var results = await session.CreateQuery(...).List<Foo>();

Internally, this could use async ADO.NET methods, so a good part of the processing would not hold a thread.
 
    Diego

[Fabio Maulo]

after use parallel

--
Fabio Maulo

[Darren Kopp]

I would second the ability for using linq statements to do deletes / updates. Yes there is hql, but some people don't use hql at all because you can use linq.

[Fabio Maulo]

Everybody uses HQL because the NH's LINQ provider is HQL based LOL!!!

--
Fabio Maulo

[pvginkel]

This is simple enough to implement through extension methods. It probably wouldn't even have to be part of NHibernate core but could easily be provided through an add-on library.

I've implemented a proof of concept in  https://github.com/pvginkel/nhibernate-core-testcase. This project has a file named MutationExtensionMethods.cs in the Mutation directory which provides the mutation functionality through extension methods. This is a very rough implementation (the update currently only works on properties and goes through reflection).

Maybe I'll pick this up.

[Ricardo Peres]

Hello, pvginkel!

Thanks for your interest! I have looked at your code, and in it you are deleting every entity manually, that is, not issuing a DELETE statement:

foreach (var record in self)
            {
                session.Delete(record);
            }

Is this just the preliminary version?

Thanks,

RP

[Ricardo]

Windows XP is not compatible with framework 4.5. The market share of XP is  still strong  in many companies.

Do you think the new features of .net 4.5 are so important to Nhibernate ?

I think you could move to .NET 4.0 for next major version of Nhibertante  and abandon XP compatibility when Microsoft launch .NET 5.0.

Ricardo

[Diego Mijelshon]

Windows XP's mainstream support ended 3 years ago, even before NH 3.0 release.

NH is used more in the server (for web apps) than in the PC [citation needed]

XP support will be retired entirely by April 8, 2014 (less than two years from now)

I'd personally kill myself if I had to work for a company that was still on XP

Do you still think it's a good idea to plan the future of NH based on the practice of companies that haven't renewed their PCs since 2006?
 
    Diego

[Richard Birkby]

I'm writing this from a corporate Windows XP machine (which was new in March 2011).

The current plan in this corporate is to go to Win7 towards the end of this year...probably after Win8/IE10 has been released.....

Richard

ps Yes, it's frustrating, but suicide is going a bit far

[Matthijs ter Woord]

Richard, just out of curiousity..

I have been in some of such corporates where versions are "slowly adopted" (ie, still on WinXP, Office 2003, SQL2000, etc, etc, you name it).
It tends to be a general symptom, not just the software (they generally tend to say things like "we're using proven technology, and not want to come across fresh bugs.."). That's the case at your site as well?
If so, then I'd say, dont take into account those situation (too much), as it likely means they wont use the newest version of NHibernate either?

(Just my 2 cents, as a non-contributor, listening on this mailinglist. If this kind of input is not appreciated, please do let me know..)

[Richard Birkby]

Yes, there's stop-energy and general bureaucracy and fiefdoms where factions form guidelines which must be followed - such as the corp loadset is WinXP or the development tool/platform is VS2008/Net35. I'm even starting to see some guidelines which say EF is the corp standard, therefore we have to move away from NH - no chance of that happening without EF getting a lot faster and gaining ADO batch support.

As to whether our project moves to the latest version of NH - well my VS pending changes window has an upgrade to NH3.3 ready to commit :-)

Richard

[Diego Mijelshon]

Of course I wasn't being literal with the suicide thing... :-)

Anyway, let's remember that switching to .NET 4.5 doesn't mean XP users won't be able to use NHibernate anymore. They'll just have to stick with NH 3.x, just like they are stuck with IE 8, VS2012 and many other pieces of outdated or soon-to-be-outdated software.
 
    Diego

[Oskar Berggren]

To me it sounds like .Net 4 contain a number of useful things like
ISet, and it feels like we should focus on those matters first.

On the other hand, if someone wants to work on features that require
Net45, perhaps we could maintain a long-lived branch, or use
conditional compilation.

What is the situation with future support for Net35? Should we aim for
a release that can be compiled on both Net35 and Net4?

/Oskar

[Diego Mijelshon]

s/VS2012/VS2010
 
    Diego

[Gerke Geurts]

The .NET 4.0 runtime and frameworks have been around sufficiently long that they should be acceptable runtime environments for most organisations. The same certainly cannot be said for the .NET 4.5 generation of products.My inclination would be to focus on .NET 4.0 and drop support for .NET 3.5.

 

Regards,

Gerke.

[Berke Sokhan]

+1 for .NET 4.0 ~ NH 4.0 

IMHO

2012/4/24 Gerke Geurts <gge...@gmail.com>

--
Berke SOKHAN.

http://twitter.com/berkesokhan
http://blog.berkesokhan.com
http://www.birliktegelistir.com/editors.aspx

[Ramon Smits]

Is it really usefull to discuss which framework to target?

I think it is more wise to discuss a roadmap with coming versions and which features those roadmap versions will contain and let that be the input to decide which framework(s) to target.

[Diego Mijelshon]

IMO, it _is_ important when it's directly related to the features each framework provides.

I believe async will be quickly become a big deal, so that's something to consider. But there's nothing* stopping us from using conditional directives to enable 4.5 features. NuGet also supports painless multi-framework packages out of the box.
 
    Diego

*: except time/resource constraints, of course

[pvginkel]

Yes, this was just a quick proof of concept; nothing near final. Thank you for your response though.

[pvginkel]

There are lots of open source projects that have custom builds for different frameworks. Through judicious application of #if's it's completely feasible to create a .NET 4.0 and a .NET 4.5 version from a single code base. I know it causes extra maintenance and complexity, but I do believe that the 4.5 features may be worth it.

[Darren Kopp]

To be fair, async is all compiler magic, so the only thing NHibernate has to do is return Task<T> and consumers could use async / await to their hearts content. It should be remembered that .net 4.5 is a superset of .net 4.0, and is separate from the compiler. The question becomes whether nhibernate will need to use the async / await keywords itself. Also, there is a project AsyncBridge that allows you to compile using the new compiler and still target 4.0, so that's an option as well. 

https://nuget.org/packages/AsyncBridge

On Tuesday, April 24, 2012 6:34:43 AM UTC-6, Diego Mijelshon wrote:

IMO, it _is_ important when it's directly related to the features each framework provides.

I believe async will be quickly become a big deal, so that's something to consider. But there's nothing* stopping us from using conditional directives to enable 4.5 features. NuGet also supports painless multi-framework packages out of the box.
 
    Diego

*: except time/resource constraints, of course

[Oren Eini (Ayende Rahien)]

Just to point out, in RavenDB we are already compatible with all the C# 5.0 magic, because we can just use Task for everything.

[Diego Mijelshon]

Async itself is compiler magic, but the ADO.NET async methods like ExecuteReaderAsync are new in 4.5.

Without those, returning tasks from NH is pretty much useless.
 
    Diego

[Oren Eini (Ayende Rahien)]

Um, no.

Task.Factory.FromAsync(cmd.BeginExecuteReader, cmd.EndExecutReader) works

[Oskar Berggren]

'async' is the new sexy of course, but it seems to me that this could
have just as well been implemented years ago:

IQuery.BeginExecute()
IQuery.EndExecute()

Perhaps that is still a good place to start?

/Oskar

[Diego Mijelshon]

That would _almost_ work but there are two problems:

- Those methods aren't part of the generic DbCommand: they are implemented in SqlCommand (not sure about other providers)

- There are no Begin/End methods for operations other than Execute (for example, Read)
 
    Diego

[Oren Eini (Ayende Rahien)]

That is because Read is on the Reader, and you are not doing async stuff there, you are reading from the in memory pool

[Diego Mijelshon]

I don't think that's correct. Check out  http://blogs.msdn.com/b/adonet/archive/2012/04/20/using-sqldatareader-s-new-async-methods-in-net-4-5-beta.aspx if you haven't yet.
 
    Diego

[Richard Birkby]

This is a timely announcement:

We would like to announce that you can now download an Async Targeting Pack for Visual Studio 11that lets you use Visual Studio 11 Beta to create projects that target .NET 4.0

 

http://blogs.msdn.com/b/bclteam/archive/2012/04/26/async-targeting-pack-for-visual-studio-11-now-available-for-net-4-and-silverlight-5-greg.aspx


Richard

[anne erdtsieck]

The asynchronous methods could be made MSSQL-only?

Op dinsdag 24 april 2012 19:38:32 UTC+2 schreef Diego Mijelshon: