Does Directus GraphQL support Enumeration types if not can it be adapted somehow?
Related
Is it possible in NEST / Elasticsearch-net 5.5 to make a custom serializer to only work on my own app's defined types and let the built in serializer handle the rest of Elastic packages own types?
I would like to accomplish this because my custom serializer is failing to serialize Elasticsearch NEST queries to json string.
It's possible to define your own JSON.NET serializer with 5.x that will serialize NEST types correctly, and serialize your own types however you like too. It's not so straightforward to do however, which is why JSON.NET was internalized in NEST 6.x :) If you're not using Json.NET, you'll need to do much more work in implementing your own serializer to do this, as your serializer will also need to know how to serialize NEST types.
For this to work in 5.x, your IContractResolver must derive from ElasticContractResolver to be able to inherit serialization of NEST types. The easier way to inherit however is to derive from JsonNetSerializer and implement the behaviour that you require in a way that does not globally affect all types that will be handled by the serializer.
Ignite-Cassandra module doesn't support Cassandra complex types like
Map type. Only BLOB and simple types which could be directly mapped
to appropriate java types are supported.
What else to get Map type from Cassandra use Ignite?
Take a look at the JavaDoc for the PersistenceStrategy enum.
There are three possible values: BLOB, POJO and PRIMITIVE. POJO strategy can be used to store maps of primitive types.
You can use this strategy in your persistence settings. Example: https://apacheignite-mix.readme.io/docs/examples#section-example-4
Thank you Denis,
But I want to persistence Map Type of java to Map Type Cassandra. Could be used only for POJO objects following Java Beans convention and having their fields of simple java type which could be directly mapped to corresponding Cassandra types. No complex type: map, list.
I'm interested to know what data is held in the MetaData annotation added to each Kotlin class.
But most fields give no more detail than
"Metadata in a custom format. The format may be different (or even absent) for different kinds."
https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/jvm/runtime/kotlin/Metadata.kt
Is there are reference somewhere that explains how to interpret this data?
kotlin.Metadata contains information about Kotlin symbols, such as their names, signatures, relations between types, etc. Some of this information is already present in the JVM signatures in the class files, but a lot is not, since there's quite a few Kotlin-specific things which JVM class files cannot represent properly: type nullability, mutable/read-only collection interfaces, declaration-site variance, and others.
No specific actions were taken to make the schema of the data encoded in this annotation public, because for most users such data is needed to introspect a program at runtime, and the Kotlin reflection library provides a nice API for that.
If you need to inspect Kotlin-specific stuff which is not exposed via the reflection API, or you're just generally curious what else is stored in that annotation, you can take a look at the implementation of kotlinx.reflect.lite. It's a light-weight library, the core of which is the protobuf-generated schema parser. There's not much supported there at the moment, but there are schemas available
which you can use to read any other data you need.
UPD (August 2018): since this was answered, we've published a new (experimental and unstable) library, which is designed to be the intended way for reading and modifying the metadata: https://discuss.kotlinlang.org/t/announcing-kotlinx-metadata-jvm-library-for-reading-modifying-metadata-of-kotlin-jvm-class-files/7980
I see that Sorm already supports org.joda.time.DateTime. Is there a possibility to add support for other types?
For example, my case class has a java.nio.charset.Charset or Locale field, which I would like to convert to a string. Suppose I have functions to accomplish the conversion from the custom type to/from a SQL type, how can I tell Sorm to use it?
SORM's support for a certain datatype is quite more complex than just ability to convert to and from an SQL type. Values of some types may span several columns (e.g. Tuple, Range), others may require intermediate tables (Seq, Set, Map) and all of them require an individual approach to translating query clauses. All that would have resulted in a quite complex ad-hoc type-mapping API if one was to be exposed.
But the thing is the above is really not the reason why such an API is not exposed and most probably not to ever be. You see, SORM's philosophy is essentially all about pure immutable data model and the cleanest way to design such one is to use standard Scala's immutable datatypes and case classes.
So the clean way for you to design your application with SORM would be to convert those stateful Java's classes to immutable values in your application. For instance you could implement a custom case class Charset (...) in your model, register it with SORM's Instance and have your conversion functions work between this type and the Java's one in your application. Besides that, you could implement this Charset as an Enumeration, which seems to be the most appropriate.
Concerning your argument about the Joda Time types support, it's there mostly because some data types were needed to represent the SQL's timestamps. See this logic as reverse to what you were thinking of.
I create xsd's based upon client's documentation and all of the xsd's have attributes. I have been using xsd.exe to generate the classes from the xsd's, but I read that attributes aren't supported for the DataContractSerializer. Why not? Does this mean that I can only have an soap+xml file with just elements? This is not possible because I don't create the requests. Is there a way to specify to svcutil to recognize attributes?
DataContractSerializer was created with a "code-first" philosophy in mind - it maps well to most programming languages (records, lists), and it doesn't handle all of XML constructs (such as attributes, or out-of-order elements, for example) for performance reasons.
WCF (svcutil) still supports using the XmlSerializer, which can handle AFAIK all of the XML constructs. svcutil should create a contract using the XmlSerializer if the DataContractSerializer can't handle it.