maria-developers team mailing list archive

[Oleksandr Byelkin <sanja@xxxxxxxxxxxxxxxx>]

Hi, Dan!

It is about DynCol.

On 06.03.2016 10:25, Dan Ungureanu wrote:
[skip]
> I am willing to implement both of them, but I am not sure whether the 
> time will allow me properly implement both of them. I cannot estimate 
> how much effort do these projects require as I am still trying to 
> become acquainted with the code base. I hope I am not underestimating 
> the projects and some guidance from one of the mentors (Oleksandr 
> Byelkin, Georg Richter or Alexey Botchkov - Holyfoot) is certainly 
> welcome.
>
> I will focus on "Import and export popular data formats from and to 
> dynamic columns" and as soon as I am done with this one, hopefully I 
> will be able to work on GIS enhancements as well.
>
> Before continuing, I would like to clarify some aspects related to 
> these projects.
>
> Import and export popular data formats from and to dynamic columns:
>
> - Can be split in four main tasks:
>
>     a) adding support for arrays (vectors) in dynamic columns. 
> Currently, dynamic columns only store dictionaries (maps);
yes
>     b) implement a library that can import (parse) and export (build 
> in a specific format) data to and from dynamic columns;
can be separate libdary or part of dyncamic colums functions set
>     c) provide interface to access to the new import and export mechanism;
If you mean Item_*.c then it is very simple interface of string function 
(mostly just a wrapper).
>     d) provide unit tests for the new features.
having c) done it can be even SQL test (mysql_test_run) which IMHO, a 
bit simplier but probably some unit tests could be written as part of b) 
and a)
> - The second part (b) of the project is mostly standalone and requires 
> little edits to the project and the third part (c) will be mostly 
> shared by the server and the C connector.
I do not think that C connector some how can be seriousely involved 
because it do not operate with some complex structures not provide 
automatic conversion. b) library just could be present and that is all. 
then JAVA connector can provide more, but it is separate task.
> - The outcome of (b) is going to be a minimal parsing and building 
> library for various formats.
I am not sure that I am 100% understand but probably yes :)
> - Some of the formats that I plan to support are: JSON, XML, CSV 
> (maybe XLS too?), PHP Array, YAML, SQL (export as INSERT INTO 
> statement?), etc. One of the key aspects I have to keep in mind when 
> designing the library is to provide a extensible interface to quickly 
> implement new formats in the future.
yes
> - Probably, most of my work will be located in:
>
>     - ./server/sql/item_*.(cc|h) - implement user defined functions
as I told it is only simple wrappers to items, not so much work.
>     - ./server/mysys/ma_dyncol.c - provide interface for user defined 
> functions
>     - ./server/include/ma_dyncol.h
what user defined functions you mean?
>     - ./mariadb-connector-c/libmariadb/mariadb_dyncol.c - provide 
> interface in C Connector
>     - ./mariadb-connector-c/include/mariadb_dyncol.h
Actually above should be the same as in the server and soon having 
connector in the server make it possible.


[skip]