maria-developers team mailing list archive

[Nirbhay Choubey <nirbhay@xxxxxxxxxxx>]

On Sun, Mar 15, 2015 at 7:48 AM, Richa Sehgal <richasehgal2908@xxxxxxxxx>
wrote:

> 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?
>

I think you hit the ld/gold issue.
https://mariadb.atlassian.net/browse/MDEV-5982

Best,
Nirbhay


> 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
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~maria-developers
> Post to     : maria-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maria-developers
> More help   : https://help.launchpad.net/ListHelp
>
>