On 30 Jan 2015 at 17:19:21, Sergei Golubchik (serg@mariadb.org) wrote:

Hi, Andras!

On Jan 30, Andras Szabo wrote:
> Hi Everyone,
>
> I am developing a custom mariadb storage backend which is intended to
> give filesystem related information via mariadb tables.
> For example one could tell:
> CREATE TEMPORARY TABLE IF NOT EXISTS `/var/log` ENGINE=fsview;
> which would create a table (using the assisted discovery method) with the following schema:

Cool!

> 1. I am having trouble implementing rnd_next() in the backend:
>
> int ha_fsview::rnd_next(uchar *buf) {
>     DBUG_ENTER(__PRETTY_FUNCTION__);
>     if (!dirp) {
>         DBUG_RETURN(HA_ERR_INTERNAL_ERROR);
>     }
>     if (struct dirent* entry = readdir(dirp)) {
>         uchar *pos = buf;
>         *pos = 0;
>         ++pos;
>         // file name (1bytes size + str)
>         *pos = strlen(entry->d_name);
>         ++pos;
>         size_t bytes_to_copy = strlen(entry->d_name);
>         memcpy(pos, entry->d_name, bytes_to_copy);
>         pos+=bytes_to_copy;
>         DBUG_PRINT("info", ("fsview filename: %s", entry->d_name));
>         // content (4 bytes size + content ptr)
>         static const std::string fake_content = "hello world";
>         int s = fake_content.size();
>         memcpy(pos, &s, sizeof(s));
>         pos+=sizeof(s);
>         const char* c = fake_content.c_str();
>         memcpy(pos, &c, sizeof(c));
>         pos+=sizeof(c);
>         DBUG_RETURN(0);
>     } else {
>         DBUG_RETURN(HA_ERR_END_OF_FILE);
>     }
> }
>
> My problem is that filenames (first field) is ok, but i cannot really
> see the expected content “hello world” in the second field. I am
> assuming that i am doing something wrong, but i cannot really find the
> reason. Could somebody help me, please?

This looks correct to me. May be, perhaps. std::string->c_str() isn't
returning the pointer to your static string (but to a some temporary
copy that gets invalidated on return)? I don't know how std::string is
supposed to work in this case.

Anyway it might've been easier to use Field methods than assembling the
row directly. Like

table->field[0]->store(entry->d_name, strlen(entry->d_name), system_charset_info);
table->field[1]->store(STRING_WITH_LEN("hello world"), system_charset_info);

> 2. If i am issuing:
>
>  SELECT * FROM `/var`;
>
> twice, then the server is not initiating a table scan again on my
> backend (most likely results from the first run are stored in some
> cache). So if filesystem contents are changed between the two
> statements, then it won’t be reflected in the resultset.
>
>  Of course if i do a:
>
>  SELECT SQL_NO_CACHE * FROM `/var`;
>
> then everything is fine, however i would not like to put the burden on
> the user to specify the option to not cache the results.
>
> My question is whether it’s possible to specify in the storage backend
> that the results from the tables should not be cached.

Yes. See handler::register_query_cache_table().

Regards,
Sergei