I want to store a list of strings in a column of a parquet table. I am able to do that using low level arrow APIs using the arrow::ListBuilder object and parquet::arrow::WriteTable call. I would like to do the same thing using the StreamWriter object too.
Apparently, StreamWriter object API does provide necessary methods for writing primitive types and strings but nothing for lists.
Is there a way to do that?
Related
I was creating my first-ever rest API in golang with fiber and form. I wanted to create a model that had a slice of strings, but gorm does not allow me to do so. SO, the next thing I tried was to use a map, hoping that it will be easily converted to JSON and saved to my postgres instance. But the same, gorm does not support maps. So, I created another struct into which I put all the data in a not-so-elegant way, where I made a single string value for each possible string I can save, and then I embedded this struct into the other. But now the compiler's complaints that I have to save a primary key into it, and not raw json given from the request. I am a bit overwhelmed by now
If someone knows I way that I can use to save all the data I need into the way that respects my requirements (slice of string, easy to parse when I read from the database), and to finish this CRUD app, I would really be thankful for that. thank you a lot
I have json array & want to group weeks according to person id's as mentioned in below example. I tried code but unable to get it because i am new to free-marker code. The JSON Array as follows:-
[{"Hours":"5.500","Status":"Draft","Week":"17","person_name":"Raj","person_id":"1414"},
{"Hours":"0.500","Status":"Draft","Week":"17","person_name":"Raj","person_id":"1414"},
{"Hours":"24.500","Status":"Draft","Week":"14","person_name":"Mukesh","person_id":"1046"},
{"Hours":"7.500","Status":"Draft","Week":"15","person_name":"Mukesh","person_id":"1046"},
{"Hours":"3.000","Status":"Draft","Week":"16","person_name":"Mukesh","person_id":"1046"}]
Could please help me. The output in below foramt
for id {1046:[14,15,16], 1414:[17,17]}
Such kind of restructuring is not something that should be done inside a template. While FTL can add together map-like values and also list-like values, it would be very inefficient to hack this together with that (it's only for very simple tasks). The entries should be already grouped before passing the data to the template.
If you must initiate this from the template, then you will need a utility Java object that has a method that does this grouping, or a TemplateMethodModelEx implementation that does it. Then you call that utility object from the template (like utils.groupByPersonId(foo) or groupByPersonId(foo)). Such utility objects can be exposed to the template on various ways: as part of the data-model, globally as "shared variable" through the freemarker.tempalte.Configuration object, or by ensuring that the utility TemplateMethodModelEx (or any other TemplateModel) class is visible for Java and then do something like <#assign groupByPersonId = 'com.example.GroupByPersonIdMethod'?new()> in the template.
I have a compiled assembly that contains a lot of my business logic rules which I would like to use inside of LINQ Pad. I can add a reference to the assembly using Query -> Query Properties, but once I have the reference how do I access the context?
My BL object expects an IMyDataSource object, not an individual IDbSet.
Normally in a LINQ Pad query, the individual DB sets are "magically" available via their names. For example
In normal .NET code I would write
Dim items As IQueryable(of Item) = DataSource.Items
but in LINQ Pad I would write it without a reference to the context.
Dim items = Items
Your LINQPad query is compiled into a sub-class of the Data Context, so your data source is available as Me. Therefor you can quality Items to Me.Items for the same result.
If you are using C# inside LINQPad, you can refer to the Data Context as simply this. For example, you can refer to the entity collection Items as this.Items and get the same results.
I used the isolated storage before to save text files, xml files and images. However, is it possible to save variables of type IEnumerable using IsolatedStorage or any other resource in windows phone 7??
Thanks,
You are misunderstanding core concepts.. There is no such thing as "saving variables", you save objects. Your variable points to an object, and that objects implements IEnumerable. Is On WP7, it is the object's actual class that determines whether that object can be serialized and stored on the ISO directly. If that actual collection class does not support serialization, you will have to re-wrap all its current elements into a List/Array/Dictionary/Stack/Queue - literally whatever what supports being serialized - and store that instead of.
Once you have an serializable collection, then your code for saving gets reduced to something as trivial as:
IsolatedStorageSettings.ApplicationSettings["blah"] = your_serializable_collection;
IsolatedStorageSettings.ApplicationSettings.Save();
and in general, that's it. Retrieving is similar:
var items = (SomeCollection)IsolatedStorageSettings.ApplicationSettings["blah"];
where SomeCollection may be an IEnumerable, a List/Array/Dictionary/Stack/Queue - whatever you had put there and whatever is implemented by the actual collection class.
If you want, you may use IsolatedStorageFile and write files directly, but unless you have a good reason to - there's no point in it, as using the common dictionary is far simplier.
In my other post you'll find some links:
How to do isolated storage in Wp7?
Use for saving/loading of data List which are serializable out of the box. Last time i tried deserialize an IEnumerable I got errors...
I'm trying to figure out how to decide when to use NSDictionary or NSCoder/NSCoding?
It seems that for general property lists and such that NSDictionary is the easy way to go that generates XML files that are easily editable outside of the application.
When dealing with custom classes that holds data or possibly other custom classes nested inside, it seems like NSCoder/NSCoding would be the better route since it will step through all the contained object classes and encode them as well when an archive command is used.
NSDictionary seems like it would take more work to get all the properties or data characteristics to a single level to be able to save it, where as NSCoder/NSCoding would automatically encode nested custom classes that implement the NSCoding interface.
Outside of it being binary data and not editable outside of your application is there a real reason to use one over the other? And along those lines is there an indicator of which way you should lean between the two? Am I missing something obvious?
Apple's documentation on object graphs has this to say:
Mac OS X serializations store a simple hierarchy of value objects, such as dictionaries, arrays, strings, and binary data. The serialization only preserves the values of the objects and their position in the hierarchy. Multiple references to the same value object might result in multiple objects when deserialized. The mutability of the objects is not maintained.
…
Mac OS X archives store an arbitrarily complex object graph. The archive preserves the identity of every object in the graph and all the relationships it has with all the other objects in the graph. When unarchived, the rebuilt object graph should, with few exceptions, be an exact copy of the original object graph.
The way I interpret this is that, if you want to store simple values, serialization (using an NSDictionary, for example) is a fine way to go. If you want to store an object graph of arbitrary types, with uniqueness and mutability preserved, using archives (with NSCoder, for example) is your best bet.
You may also want to read Apple's Archives and Serializations Programming Guide for Cocoa, of which the aforelinked page on object graphs is a part, as it covers this topic well.
I am NOT a big fan of using NSCoding/NSCoder/NSArchiver (we need to pick a name!) to serialise an object graph to a file.
Archives created in this way are incredibly fragile. If you save an object of class Foo then by golly you need to make sure when you load the data back in you have a class Foo in your application.
This makes NSCoder based serialisation difficult from the perspective of sharing files with other applications or even forwards compatibility with your future application.
I forgot to list what I would recommend.
NSCoding can be ok in certain situations: if you're just doing something quick and simple (although you do have to write a lot of code - two methods per class to be serialised). It can also be ok if you're not worried about compatibility with other applications.
Export/import via property lists (perhaps using the NSPropertyListSerializaion class) is a fine solution. XML based plists are easy to create and edit. Main advantage to plists is that you're not tying the file format to just your application.
You can also create your own XML based file format and read/write to it using NSXMLDocument API and friends. This really isn't much more work than using property lists.
I think you're a bit confused, NSDictionary is a data structure, it also happens to implement the NSCoding protocol. So in essence, you could either put all your data into a NSDictionary and have that encode itself later on, or you can implement the NSCoding protocol and encode your object tree using the NSCoder API. Based on the type of NSCoder object passed in to the encodeWithCoder: method, is the output of your encoding.