Thank you for your informative reply Oskar. This is my tentative plan so far:
- Propose a new scalar HQL function called dateadd() modelled after DATEADD() <https://msdn.microsoft.com/en-us/library/ms186819.aspx> in SQL Server. (This will probably break a few custom dialects around the world.. commentary especially welcome on the choice of name) - Create HQL unit tests that covers as much as possible of the functionality of DATEADD() in SQL Server. - Attempt to implement the dateadd() function and make the unit tests pass for the SQL Server dialect. - Attempt to implement as much as possible of the dateadd() function for MySQL, PostGreSQL, Oracle and SQLite. - When all that is done and works well, an attempt can be made to implement LINQ support, in a phase 2 of sorts. Most of the useful .Net DateTime API should translate easily to dateadd(). Is this a reasonable plan? Am I way off the mark? Is there something I'm forgetting or should consider further? I realize that I am engaging in a slightly bigger task than I initially thought, so that's why I am scoping the task to dateadd() first to see how that works out. -Andreas On Saturday, April 11, 2015 at 1:43:25 AM UTC+2, Oskar Berggren wrote: > > What I meant in the issue was that the current lack of support wasn't a > bug, but adding support for it would be regarded as a new feature. Seems > doable to me. > > You need to decide on a set of names for the HQL functions that will > underpin the linq support. These functions must have the same semantics > regardless of SQL dialect. The dialect classes will need to translate them > into appropriate SQL constructs depending on SQL variety. Usually it's not > very difficult. Implementations should be provided for at least 4-5 of the > most common dialects, the more the better, before inclusion. > > The linq layer then needs a few fairly simple additions to teach it about > the HQL methods. Doesn't need to know about different dialects. > > You can perhaps review how Substring() is handled in linq and the dialects > for inspiration. > > /Oskar > Den 8 apr 2015 22:59 skrev "Andreas Ravnestad" <[email protected] > <javascript:>>: > >> Hi Ricardo, >> >> It is only mentioned briefly in the subject of my post, but I was >> planning to scope the implementation to the Microsoft SQL Server dialect >> since that's the database engine we are using. Perhaps this is undesirable? >> >> -Andreas >> >> >> On Wednesday, April 8, 2015 at 9:44:40 PM UTC+2, Ricardo Peres wrote: >>> >>> The problem is what Oskar said in the issue: Since LINQ is translated to >>> HQL and HQL has no support for date operations like, for example, SQL >>> Server's DATEADD, this might be tricky, because possibly - and I'm not 100% >>> sure on this - Dialects need to be involved. >>> >>> RP >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "nhibernate-development" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] >> <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- --- You received this message because you are subscribed to the Google Groups "nhibernate-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
