openerp-expert-framework team mailing list archive

[Leonardo Pistone <leonardo.pistone@xxxxxxxxxxxxxx>]

FYI, the regexp search in the sparse attributes:

http://bazaar.launchpad.net/~camptocamp/openerp-product-attributes/6.1-backport-lot-custom-attributes-lep/view/head:/production_lot_custom_attributes/lot.py#L34

The MP is here:
https://code.launchpad.net/~camptocamp/openerp-product-attributes/6.1-backport-lot-custom-attributes-lep/+merge/196538

Thanks


On Tue, Dec 10, 2013 at 2:18 PM, Leonardo Pistone <
leonardo.pistone@xxxxxxxxxxxxxx> wrote:

> Thanks for yor answer Raphael.
>
> On the long run, I agree with you that using a native Postgresql field
> seems like the obvious choice.
>
> For now, searching in the text-based json fields seems something to
> implement with a Regexp. Otherwise, maybe with postgresql 9.2 we can use
> the native json methods to search in the text field, but I'm not sure.
>
> Best, Leo
>
>
> On Tue, Dec 10, 2013 at 2:07 PM, Raphael Valyi <rvalyi@xxxxxxxxx> wrote:
>
>> On Tue, Dec 10, 2013 at 10:54 AM, Leonardo Pistone <
>> leonardo.pistone@xxxxxxxxxxxxxx> wrote:
>>
>>> Hi all,
>>>
>>> Has anyone worked on a search() method for JSON-serialized sparse fields?
>>>
>>> In theory, one could use postgresql's JSON features introduced in 9.2,
>>> or failing that, some (dirty) regexp to build the search query.
>>>
>>> Any ideas or suggestions?
>>>
>>> I've seen Therp's unserialize_field, but I like to stay serialized :)
>>>
>>> Thanks!
>>>
>>
>>
>> Hello Leonardo,
>>
>> For flexibility I would favor evolving the sparse field feature from a
>> text field to a native PostgreSQL json field. I mean I say this because I
>> think it's better than moving to hstore and getting the search feature from
>> hstore.
>> I have some experience extending custom_product_attributes into a product
>> configurator (though funding was dropped 2 years ago) and I can tell you
>> nesting is definitely a must have in the big picture.
>> See http://www.craigkerstiens.com/2013/07/03/hstore-vs-json/
>>
>> Then yes, I would naively go for building a regexp to add some search
>> support upon a full text indexed field.
>>
>> Also notice that if you admit a heavier solution, I built an Apache SolR
>> connector providing much more advanced search features
>> https://github.com/akretion/solerp/tree/master/solerp
>> The real case I've been working has nearly 1 millions of products indexed
>> into Apache SolR, and it's indexing thousands of attributes that use the
>> product_custom_attributes and hence sparse fields NOSQL power.
>>
>> I'm curious what other think about this too.
>>
>> Regards.
>>
>> --
>> Raphaël Valyi
>> Founder and consultant
>> http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
>> +55 21 2516 2954
>> www.akretion.com
>>
>>
>>
>