On Thu, Jun 1, 2017 at 10:05 AM, Frédéric Delaporte
<fredericdelapo...@free.fr> wrote:
> NHibernate Teamcity build agent is currently a Windows Server 2012 R2. Are
> you meaning Sql Server 2016 can only run on Windows 10/Server 2016? There is
> already a SQL server 2016 on that server.
>
> According to
> https://docs.microsoft.com/en-us/sql/sql-server/install/hardware-and-software-requirements-for-installing-sql-server,
> it runs under Windows 8 and Server 2012. So not on a Windows 7, but not only
> Windows10+. Indeed they have released it for all OS still in mainstream
> support (8/2012+), but not for those in extended support (7/2008, ending in
> 2020).
Yes, thank you for clarifying. Windows 8/2012+. Point is, no upgrade
path for Windows 7 users, at least not today.
> Anyway, that should not prevent adding feature targeting a server not
> testable by some developers: NHibernate test suit can be configured by each
> developer to target what they have, and then it will ignore incompatible
> feature tests.
>
> About supporting JSON querying with an API abstracting away databases
> specificity, of course it would be great. But since each db seem to go its
> own path without much standardization, it may require too much effort. I see
> that a bit like XML support, NHibernate do not provide a way to issue "for
> xml" queries likely because this has to much discrepancies from a database
> to another.
Supporting an agnostic Xml/XPath scenario shouldn't be too terribly
difficult IMO. As you say, it's a pathing issue, among other Xml
nuances, attributes, elements, etc.
> Now for JSON that seems way more simpler than XML, so why not trying anyway.
>
> For me, there are two distinct areas to tackle:
>
> How NHibernate map a Json data on an entity?
I could be wrong, but it seems to me a "simple" {"property": "value"}
approach would be *too* simple. How would you capture type
information? That would be key, to have a richer mechanism, like
{"property": {"type": "System.Object", "value": "value"}}. Just for
example. Of course, then there is the matter of value conversion
to/from strings, ostensibly.
> I think NHibernate should let the user map it as a plain string if he wants
> to. This may requires a JsonAsStringType for database defining a column as
> Json, or adapting the string type for handling those Json type. (May some
> data provider already provide deserialized values? If yes, it would have to
> serialize them back...)
> And Nhibernate should provide a type for mapping it as a poco (which class
> would be specified along the mapping otherwise inferred from the entity
> property).
> Having some dynamic mapping option would be great to. Maybe through
> dictionaries, for avoiding introducing a dependency on Json.Net or the not
> yet released System.Json on the entities (I only find obsolete Silverlight
> references for it or a pre-release Microsoft package).
> Of course, depending on how the data provider handles Json (does it handle
> serialization/deserialization or does it handle only already serialized
> Json?), NHibernate will still need to use a Json deserializer/serializer,
> and preferably a fast one like Json.Net. But this could be done through some
> Json serialization/deserialization provider, allowing the user to customize
> this.
> Supporting the SQL Server way means here we would also support any database
> even if not officially supporting Json.
> How NHibernate query Json data directly in the db? Here explicit database
> support is of course mandatory. And maybe the discrepancies between db will
> cause some difficulties.
> Maybe should we first start by providing two basic HQL function taking the
> json path as a string and mapping to json_value/json_query (or the unique
> function for db having one for all). And supply two extensions for calling
> them with Linq.
> That would already allow a basic querying support. This suppose the json
> path has the same syntax for all databases. Otherwise we will have to choose
> one syntax and convert it for other databases.
> From there, maybe try if we can propose something more elaborated.
>
>
> --
>
> ---
> 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 nhibernate-development+unsubscr...@googlegroups.com.
> 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 nhibernate-development+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
