Views integration troubles

Regarding the original post: I could reproduce neither. What were the exact steps you performed? And have you updated both modules and cleared the caches?

Regarding #1: This should probably be a seperate issue, since the main module doesn't support fields either, at the moment. (Which is an important problem, so should have an isssue anyways. So I'll create one. So I created one: #939822: Support fields. Please help there, that will then also cover views integration.)

As said, I can't reproduce this. Everything works fine here (at least regarding this aspect), and yes, I have tried filtering on the node type. Didn't you do anything special, and have you really the latest versions of everything?
(Btw, just discovered your view() addition clashes with my own view(), will have to change that too in the announced API change (probably tomorrow). And that's how one API change begets another … ;P)

Regarding the re-use of Views handlers: Of course, I thought about it and it would make sense – but then, every handler would have to override the same methods that work in an SQL-specific way in the standard handlers. And I'm still of the opinion that this would be more unnecessary duplication than when we re-implement the standard handlers' useful extra features.
You can just create a feature request to add those, when some are needed (which I'm sure there are).

I also have some problems with views filters. I tried to show them in a little video: http://blip.tv/file/4265168

I am on latest version of core(ok, until yesterday at commit #731044 by sivaji: Fixed ambiguous column name changed in certain database systems.), entity, search_api and almost the last views(without the last three commits, but those IMO are unrelated, for reference the commits are: #882800 by rszrama: Fix notice for options['distinct'], modules/taxonomy/views_handler_filter_vocabulary_machine_name.inc and #667950 by damZ, dereine: Port #dependency form elements to #states.)

I think there is some work to do to map correctly the filter's type, for example I do not understand options like ">=" on boolean fields or why I can not enter two words on the title field filter, what is the expected input at date fields like node creation("value" is a strstotime?)

In the other hand, to actually perform that filters, I need to store the complete value of the field at the index of the search engine(for example a complete string field to be able then filter by comparing with that value that is not indexed as fulltext) and that seems to be the only way to achieve filters(sorry, random though, but correct me if I'm wrong)

BTW if you turn on E_STRICT, you are going to see a lot of things that maybe influence this troubles.

PS: ignore the one-line debug I included that print a message per field with drupal_set_message(aka I forgot to remove it before recording).

dup at the time d.o was unstable for redesing :-p, sorry

for example I do not understand options like ">=" on boolean fields

Ah, yes, that was a bit of an oversight on my part. Should be fixed now.

why I can not enter two words on the title field filter

This seems to be a problem with the database search, not with the Views integration. I created a seperate issue: #946286: Multi-term fulltext filter results in exception. Currently I couldn't figure out what causes the error.

what is the expected input at date fields like node creation

Sorry, another oversight! Should also be fixed now.
Trouble is, I can't test those completely, at the moment, since part of this seems broken in Views, too. I tried to create a Node view with some filter and it failed even more horribly than with my query class. Not a good sign …
So in any case, I'll have to re-visit this once Views has become a bit more usable again …

Thanks for pointing all those out!
And also thanks for the video, always helps. Although you should probably keep it a little more concise, the bugs are clear anyways, once you see them.

In the other hand, to actually perform that filters, I need to store the complete value of the field at the index of the search engine(for example a complete string field to be able then filter by comparing with that value that is not indexed as fulltext) and that seems to be the only way to achieve filters(sorry, random though, but correct me if I'm wrong)

Sorry, I don't really know what you want to say with that.

BTW if you turn on E_STRICT, you are going to see a lot of things that maybe influence this troubles.

No, these don't influence this – in fact, they ensure that things go right in one aspect. They are just warnings because Views is far away from complying to most of Drupal's OOP-related coding standards, and I don't want to do that to my module, too.
I'm sorry that developers with E_STRICT error reporting now have to see these, but the correct fix would probably be to go to the Views issue queue and tell them to adopt the "new" Drupal coding standards.

P.S.: Oh, and you posted twice, by accident – you might want to edit one to clear this up a bit.

As you mentioned, some of the problem must be on views side, but it is actually a good time to report them if we can figured out at least how to reproduce the problem.

About the video, sorry, I know it was too large, I'm going to do a better job next time ;-)