Is it possible to have custom serializer on single aerospike set? I do not want my serializer to be used on other sets in the namespace.
Aerospike allows flex schema. You do not need to define the type of the set or bin upfront. You can encode every bin the way you want. So, whatever data you want to store with AVRO serialization, you can store it as a blob type.
Related
Is there a way to create an "Alias" or a "soft-link" of a subject in schema registry?
I'm asking this is because for certain kafka topics, they share a common schema
e.g.
topic names:
{env}.{level}.{schema_name}.{producer_name}.{realtime|batch}
schema subject:
{env}.{level}.{schema_name}.{version}
When I set up confluent s3 sink connector, the connector avro converter follows topicNameStrategy to derive schema subject from topic name so the schema name is derived to be {topicName}-value
Is there a way for me to create alias {topicName}-value which actually points to {env}.{level}.{schema_name}.{version} in schema registry? I'm trying to avoid duplicating schemas in schema registry or any significant changes in current kafka topics.
Thanks.
When I set up confluent s3 sink connector, the connector avro converter follows topicNameStrategy
You can set value.converter.value.subject.name.strategy to change that.
But that means you need to write your own class to get custom one not offered by Confluent. Sounds like your producer's are already using the same class to register those formats in the Registry rather than also the default {topic}-value, anyway.
The only way to "alias" is to explicitly make the HTTP requests to PUT a new version of a new subject after GET request against the "original". You aren't duplicating anything more than metadata since the schema will remain the same. The main downside is that there is no "linking" between the "aliases" since such a concept doesn't really exist, and therefore, you need to remember to change all subjects.
Personally, I used the pattern of hard-coding env=DEV/level=FOO/ in the topics.dir setting, then the topic names were underneath that. If you have dynamic values, then put those fields in the record itself, and use S3 Connect's FieldPartitioner to accomplish the same thing
I'm wrinting a very simple application which can read data from a specified file and populate the fetched data to a NSTableView. The file is a plain text file where each line represents an object (I need to parse the file). I want to use Core Data and my question is what is the Cocoa way to do that?
My first idea is to parse the file and create instances for the Entity which represents one line. I'm not sure that is it the best solution. And later I'll write out the changes to the file (after save? or automatically after a given amount of time?)
My configuration is Mountain Lion and the latest XCode.
A single entity with a number of attributes sounds good. If you had an attribute which holds a reasonable amount of data and was repeated on a number of 'rows' then it would be a candidate for another entity.
Yes, each instance of your entity would represent one row in your table.
Personally, I would either save on request by the user, or not have a save button and save each change. Your issue is the conversion between your in-memory store and on-disk store. Using a plain text file doesn't help (though, depending on the file format, it could be possible to edit individual lines in the file using NSFileHandle).
Generally it would still make more sense to use a better format like XML or JSON and then make use of a framework like RestKit which will do all of the parsing and mapping for you (after you specify the mapping configuration).
You can also use bindings to connect your data to your NSTableView. Another ref.
I'm pretty new to Core Data, and I'm trying to wrap my head around it.
You might have cases where you want different types of data stored in different places or with different behaviors. For example you might have one read only sqlite store shipped as part of your app containing some default data, an additional store for updates to that data set you have downloaded from a server, and a third for user data. Alternately you might have a case where you want some objects to be persisted while others can live in an in-memory store and do not need to be saved between uses of the app.
I try to use blobs as little as possible. When possible I replace blobs by a link to a file. I can only think of a few times that I needed a blob. I used to put zipped pickled python objects in there, but I use mongo or couchdb these days for that. One thing I still use it for is to store wkb (gis) objects. This made me wonder, what do other people put in their blob fields?
Whatever binary data needs to be stored - typically images & documents (Word, PDF).
They have disadvantages..., so tried to ignore them, especially now file-stream exists in SQL2008.
BLOB accepts any data, all the items stored in the BLOB are stored in whole disk pages in separate disk areas from normal row data. Normally in a BLOB you can store any data generated by your program, images, graphics, video, audio or different types of documents.
I have a flat file from one application, which I have to send to a BizTalk server. In that case which component in my BizTalk server converts my flat file to XML.
Also I heard that I have to create an input schema (.xsd file), why do I need an input message schema?
The component in BizTalk that performs the conversion is known as the Flat File Disassembler. It is a component that lives in the incoming pipeline selected in the Receive Location that listens to your incoming message.
You need to create a special XSD schema to drive the conversion process. This schema is known as a Flat File Schema. In fact, it is a valid XSD schema that contains additional proprietary annotations used at runtime by the Disassembler in order to perform the conversion. Those annotations consist in describing the original flat file structure in terms of data types, length, offets, etc.
There is no builtin pipeline that you can use for this purpose however ; you need to create a custom receive pipeline, and drop the Flat File Disassembler component in the Disassembler stage. Then you can configure the dissassembler to use your custom Flat File Schema.
Hope this helps.
If you are wanting to read and manipulate the contents of the flat file you have to convert it to XML which is the basis of all messages in BizTalk.
This allows you to
Promote properties in the message for routing
Transform it into another XML message format.
Enrich the message.
Emit it in a new format (flatfile, XML, EDI etc.)
However if all you are wanting to do is to move the flat file from one location to another, you can just use the passthru pipelines, in which case you don't need to convert it to XML or need a XSD.