I think if the fields are exposed to the entity module using hook_entity_property_info() then the fields can be indexed by search api.

Comments

fietserwin’s picture

Status: Active » Postponed (maintainer needs more info)

I'm always willing to implement hooks from other modules. I'm not familiar with the Entity or Search API. So can you explain a bit what will it buy you or us or someone else? What else would I need to implement (callbacks, etc.)

drunken monkey’s picture

I don't know, does this module provide a new entity type, or new field types? In the former case this page should contain the information on how to do this. Otherwise you are stuck with the little information here and will likely need to look at the example in the Entity API on what to provide in the field info hook.

Regarding what this buys you, and users of your module: the property information of your entities / fields becomes available to other modules in a generic way. This is then used, e.g., by Rules to allow rules based on entity properties, or by the Search API to make the entity data easily searchable. Token integration also comes free with this, I think, if you don't have it already.

fietserwin’s picture

Moving to Availability Calendars. I moved the sandbox code into a new version of that module and it will be continued over there. So this project will be abandoned.

@ drunken monkey: thanks for entering the discussion. This module provides a field. I'm still not sure about being indexed by search API as the fields do not contain any text (yet). Rules integration looks more realistic, thinking of processing an external booking thereby updating the availability.

fietserwin’s picture

Project: » Availability Calendars
Version: » 7.x-3.x-dev
drunken monkey’s picture

@ drunken monkey: thanks for entering the discussion. This module provides a field. I'm still not sure about being indexed by search API as the fields do not contain any text (yet). Rules integration looks more realistic, thinking of processing an external booking thereby updating the availability.

So what type does the field have, what does it contain? The data can be indexed in any case and, e.g., used for filtering or sorting. Facets with the field value could also make sense, and would then be possible.

fietserwin’s picture

The field data just refers to data in other tables (like file and image fields). These other tables contain just dates and an availability state associated with that date. Ok, not completely true: It also keeps separate created and changed timestamps for the calendars (many holiday home search sites rank offers with recently updated availability higher). So this could be a target for filtering and sorting like I added for Views?

drunken monkey’s picture

Yes. You could define either entity references, or new properties based on the calculations you do, or both, for your field's property info, or maybe also for the other entity types' infos. I still don't have a clear picture of what the field or module does, so can only guess, but this should surely add some additional value.

bjalford’s picture

Has anyone implemented this yet?

danielm’s picture

Hi,
It would be better if search by date is available with search api module.

Indeed it is what can be found in most websites

Thanks

fietserwin’s picture

Can you explain?

To me Search API is about that "little textfield in the upper right corner" and that is meant for a free text search. Do you expect people to fill in a date there and then get a list of available entities?

danielm’s picture

Thanks for your response.
Yes that's it

fietserwin’s picture

With or without a date picker?
Free date format, thus both mm/dd/yyyy and dd/mm/yyyy?
Date ranges allowed, something like dd-mm-yyyy - dd-mm-yyyy?

Ooff, I think that most websites offer availability search in a structured search that also allows to filter on geographical location, number of persons, price category, etc, etc.

danielm’s picture

Hi,

Date ranges by language url.
Example:
- US mysite.xyz/en = mm/dd/yyyy - mm/dd/yyyy
- FR mysite.xyz/fr = dd/mm/yyyy - dd/mm/yyyy
- ES mysite.xyz/es = dd/mm/yyyy - dd/mm/yyyy

Yes you're right, also allow to filter on geographical location, number of persons, price category, etc, etc

Thanks

danielm’s picture

Sorry I forgot:
Or date ranges by language url.
Example:
- US mysite.us = mm/dd/yyyy - mm/dd/yyyy
- FR mysite.fr = dd/mm/yyyy - dd/mm/yyyy
- ES mysite.es = dd/mm/yyyy - dd/mm/yyyy

Thanks

danielm’s picture

No news?

fietserwin’s picture

Version: 7.x-3.x-dev » 7.x-5.x-dev
Status: Postponed (maintainer needs more info) » Needs review

I managed to create some integration with Search API. Utterly complex, as Search API does not like complex properties and its evenly complex conditions, but anyway.

For now, it only works with search_api_db as server and search_api_views as frontend, but hopefully search_api_page and apache solr will follow.

Could you all test the functionality in the new 7.x-5.x-dev branch (dated march 18 or later) and report your findings here? Please do read the instructions in the README.txt.

davewilly’s picture

Issue summary: View changes

Are there any plans to further the integration with Search API? As I understand, it currently only works with search_api_db. Many thanks, insanely awesome module.

fietserwin’s picture

This has been a while since I managed to get some integration with search API. Since then I have thought a lot about ways to represent availability in an easier way and I think I did found a way to do so, but did not yet implement so. Currently I have not much time to spare for maintaining modules, but if you really need this feature, contact me to see if you or one of your project members can implement it.

fietserwin’s picture

Status: Needs review » Closed (works as designed)

Kind of duplicate of #2468229: Search api indexing. See my latest remark over there.