We used Nest.Dsl.Factory add-on to NEST library with earlier versions of NEST. Now that it's approaching version 1, it looks that Nest.Dsl.Factory is no longer supported. I wonder if NEST has now similar functionality built into the core package.
The DSL Factory DSL has indeed been dropped, after it was donated it became unmaintained.
See the release notes for 0.11.7.0
https://github.com/elasticsearch/elasticsearch-net/releases/tag/0.11.7.0
You should now switch to the fluent lambda syntax or use the new object initializer syntax.
Fluent syntax:
http://nest.azurewebsites.net/nest/core/search.html
http://nest.azurewebsites.net/nest/writing-queries.html
Example initializer syntax:
See this unit test
The object initializer syntax is something we are rolling out for all the API endpoints for the 1.0 release but is currently only available in our continuous builds on myget.org
https://www.myget.org/gallery/elasticsearch-net
Related
We use a Java type generator to modify our enum type from Swagger 2.0 to a Java enum, and there are cases where we have needed to deserialize enum values that we've removed from our codebase, so for now we need to keep these deprecated enum values.
Can we somehow mark them in Swagger 2.0 as deprecated? I don't see a way to do so in either Swagger 2.0 or 3.0.
Unfortunately it is not possible to achieve this with either versions. However as of 3.1 it is possible. Have a look at this article that explains this in debt: https://community.smartbear.com/t5/Swagger-Open-Source-Tools/Swagger-Enum-Deprecated-Values-Is-it-possible/td-p/207289
I am using a cloud service which is building on protobuf2.0. This cloud service cannot be changed.
Now we have client to connect to this cloud service, which is built on .netcore 2.0.
As I test, that .netcore only works with protobuf3.0 syntax.
And 3.0 syntax is little different with 2.0. If I deploy client with protobuf3.0 in C# .netcore 2.0, can it consume the service which is built on 2.0 protobuf?
The actual binary serialization format hasn't changed at all in this time, so there are no fundamental blockers.
The biggest feature difference between proto2 and proto3 is the treatment of default / optional values. Proto3 has no concept of "the default value is 4" (defaults are always zero/nil), and has no concept of explicitly specifying a value that happens to also be the default value (non-zero values are always sent, zeros are never sent). So if your proto2 schema makes use of non-zero defaults, it can be awkward to transition.
As I test, that .netcore only works with protobuf3.0 syntax.
That statement makes me think you're not using protobuf-net (tags), bit are in fact using Google's C# implementation - Jon's original port was proto2 only, and the version migrated to the Google codebase is proto3 only. However, protobuf-net (a separate implementation) has no such limitation, and supports both proto2 and proto3 on all platforms including .NET Core. It does have a different API, however. Protobuf-net can be found on nuget, with a .proto processing tool available here (it also provides access to all the "protoc" outputs if you want to compare to the Google version).
It seems that the new java.time API offers everything from java.util.Date and much more.
Is there any reason to use java.util.Date when the newer java.time API is there since Java 8?
Should java.util.Date and java.util.Calendar be avoided completely?
Short answer: The new API java.time is way better than the old world with java.util.Date and java.util.Calendar. So yes, the new API should be preferred in new code.
For a quick overview: Once I had written a comparison of features in table form for various date-time-libraries. There is almost no feature which java.time is missing but exists in the old world:
configurable gregorian/julian cutover
printing based on the class FieldPosition (used in Swing-component FormattedTextField)
About deprecation: Although most parts of java.util.Date are deprecated since Java 1.1, the class itself (and java.util.Calendar, too) are not officially deprecated, just declared as de facto legacy. The support of the old classes is still important for the goal of backwards compatibility with legacy code. So Oracle will probably not stop the support at any time in the future. But maybe Oracle will apply more sophisticated deprecation strategies.
Future development: It is interesting that the release of Java-8 has not only incorporated a completely new date/time-API (java.time) but also seen some few enhancements to java.util.Calendar, for example Calendar.Builder or SHORT_STANDALONE etc. Well, I can only speculate but this also seems to indicate that Oracle is not willing to stop the support of the old API in the near future.
From what I understand, SAXON is the only library which supports XPath 3.0 in Java.
Its JAXP implementation only supports XPath 2.0.
Its XPath 3.0 implementation should be called this way and requires me to build the document in the first place with its own API rather than using a JAXP-compliant API like DOM4J.
This is a pain because I'd been careful to abstract away everything that uses XPath to a proxy interface taking a JAXP node and xpath string as parameters, but this seems pointless if I have to refactor everything to use SAXON nodes from the top down.
Am I misunderstanding something? Is there a less painful way?
I'm increasingly trying to encourage users to use the s9api API in preference to JAXP for XPath processing. There are a variety of reasons: the JAXP interface only gives very half-hearted support to tree models other than DOM; it really struggles with the extended type system of XPath 2.0 and now 3.0, and in the case of Saxon, it doesn't interoperate at all well with other XML technologies and APIs.
However, Saxon continues to support the JAXP XPath API, with all its limitations, both against its own tree model and against third-party tree models such as DOM4J.
One thing that we have dropped is support for the XPath services interface, whereby an application using the XPathFactory.newInstance() method will pick up Saxon if it's on the classpath. The reason for that is that you really need to know when you're writing an application whether you want an XPath 1.0 or 2.0 processor, and the JAXP mechanism gives you no way of saying which you want, or discovering which you have been given. The result was that a lot of applications were experiencing hard-to-diagnose failures when deployed with an incorrect classpath. If you want Saxon as your JAXP XPath provider you now have to ask for it explicitly.
It would be useful if you could be more specific about what you are trying to do, and how it is failing.
I am very new to Spring JDBC and working on a given task, looking at the codes we already have my teammates have used RowMapper, but I was doing some Googling and saw some tutorials are using ParameterizedRowMapper , so I was wondering if there is any benefit or good practice in using one rather than the other one and your technical thoughts behind that...
thanks.
Right from the javadoc of ParameterizedRowMapper:
Extension of the RowMapper interface, adding type parameterization. As
of Spring 3.0, this is equivalent to using the RowMapper interface
directly.
Prior to Spring 3.0, most APIs did not use generics because Java 1.5 wasn't a requirement. As a result, there was a RowMapper, that didn't support generics and ParameterizedRowMapper that did support generics by extending RowMapper and adding the generic parameter. As of Spring 3.0, most APIs were updated to support generics. If you actually look at the current (3.0 or greater) definition of ParameterizedRowMapper, it just simply extends RowMapper and adds nothing to the definition to allow for backward compatibility. Therefore, you can pretty much use RowMapper either parameterized or not and no need to use ParameterizedRowMapper.