maria-developers team mailing list archive

[Richa Sehgal <richasehgal2908@xxxxxxxxx>]

Dear Sergei and Maria community,

Finally I have settled on one project: Indexing over virtual columns.

I spent the entire day today trying to compile MariaDB in Ubuntu and
reading the code. On reading code side, I spent some time in the
/storage/myiasm/ : read fiels like mi_key.cc, mi_create.cc, ha_myisam and
so on. Took a brief overview arounf _mi_make_key function. I also looked
around update_virtual_fields() function.

The code path is still not very clear to me - especially the transition
point between sql folders to /storage folders. I chatted on #maria IRC and
they gave an idea to run Maria in gdb mode. I tried compiling the code  it
was almost successful! At the very final step, I got the following error:

[ 98%] Built target thr_lock
Linking CXX shared library libmysqlclient.so
/usr/bin/ld: error:
/home/shikhar/mariadb/maria/trunk/libmysql/libmysql_versions.ld:155:9:
invalid use of VERSION in input file
collect2: ld returned 1 exit status
make[2]: *** [libmysql/libmysqlclient.so.18.0.0] Error 1
make[1]: *** [libmysql/CMakeFiles/libmysql.dir/all] Error 2
make: *** [all] Error 2

I am not able to proceed now. I tred googling around, but could not find
the fix. Can you please guide me in my next steps?

Thanks
Richa

On Sat, Mar 14, 2015 at 10:46 AM, Sergei Golubchik <serg@xxxxxxxxxxx> wrote:

> Hi, Richa!
>
> On Mar 14, Richa Sehgal wrote:
> > Thanks Sergei for the explanation. The modified project for MDEV-5199
> > (Table Functions) now makes sense - as in the proposals mentioned in the
> > ticket as possible solutions now looks appropriate :)
> >
> > I am looking into the index of virtual columns. One question: can we
> submit
> > proposals for 2 projects at MariaDB?
>
> We don't mind, but rules are set by Google, if they allow it - you can,
> otherwise you cannot.
>
> > Now as for Table Functions:
> >
> > As mentioned there are two ways:
> > 1. Materializing the table - this has a disadvantage for extra space.
> > 2. Treating the UDF result as an "abstract table". For eg, the code might
> > have a base class called Table. Then we can create a derived class called
> > UDFTable and pass this instance in the regular query processing. This
> class
> > would implement all functionalities like Init(), Next(), Read(int
> > col_index), Seek(), etc
> > Consider:
> >  Select A where A.x > 10 FROM UDF_TABLE
> >
> > In this case, we will first construct the table UDF_TABLE through regular
> > query - evaluation of the UDF. Then we can create an instance of UDFTable
> > from the table and run normal query processing on this.
> >
> > Is this the right approach? Can you send me the next steps?
>
> the "abstract table" that can do Next, Read, Seek, etc in MariaDB is
> represented by the "handler" class. All real storage engines inherit
> from the handler class.
>
> See the SEQUENCE engine, it's in the storage/sequence/sequence.cc
> This is, exactly, the engine that generates data on the fly, so is a
> table function, in a sense. But it's a hard-coded function and the way
> of passing arguments is not very nice. Still, it'll give you an idea
> what a table function handler might look like.
>
> If you want an even simpler storage engines - there are some in our
> book, "MySQL 5.1 Plugin Development".
>
> Regards,
> Sergei
>
>