← Back to team overview

openerp-community team mailing list archive

Re: openerp-connector and elasticsearch

 

@Guewen,

just a note to tell that a per product export is how I implemented
https://github.com/akretion/solerp/tree/master/solerp and this is exactly
where I use your queue framework.

On Mon, Nov 25, 2013 at 11:48 AM, Rodrigue Villetard <
rodrigue.villetard@xxxxxxxxxxx> wrote:

>
> Hello Raphaël,
>
> Solr vs elasticsearch… Well, after some researches, I came to elastisearch
> for two very simple reason: I like JSON REST apis and elasticsearch has an
> archive to download of 20Mo (Solr > 130Mo). The other functionalities seem
> rather equivalent and always counter-balanced, so I took the one with the
> better showcase!
>
> But, as you have started a solr connector, I may change my choice. It’s
> not too late for that and it is better if we are numerous on a same
> solution.
>

We may change to in case Elasticsearch where really proving better (not my
feeling today). In fact we already had SolR knowledge and I had the
opportunity to follow the SolR Unleashed training, that's why for now.
If you like you can join forces now to have something working quick. Later
if you convince me Elastic Search is better we port the stuff to Elastic
Search. BTW SolR is just as json as ElasticSearch I believe. Now yes, there
is 130 Mo, but when you should do bzr branch lp:ocb-addons , this becomes
negligible ;-)


> I am building a Service Oriented Architecture with :
>
> webapp
>   |--> readonly solr or elasticsearch
>   |--> very little django based rest api for managing baskets, auth and so
> on
>                |--> openerp
>

My architecture is pretty much similar...
Are you allergic to Ruby on Rails? If not I have built some killer open
source framework for such architecture... My Django is replaced by Rails in
my case and I have terrific layers over the OOOR connector that allows me
to edit OpenERP data as if it was a pure Rails app when user needs to
interact with the data. Else it's all handled by SolR with rsolr and
blacklight, https://github.com/projectblacklight/blacklight, a technology
built at Standford university and now powering many other US universities
http://projecthydra.org/

Just a word to tell that i my case I have no extra front-end database
(except a simple front-end User table managed by Devise
https://github.com/plataformatec/devise)  like you may have with
Prestashop. Aside from being extremely fast, it also has the advantage that
there no data duplication like you have in traditional Prestashop or
Magento connectors and which create some operational and maintenance cost.
Say Apache SolR is just a cache that you can trust 100% to be up to date
after 1 or 2 seconds with OpenERP data, else the data is all managed in
OpenERP in a normalized way.
An other characteristic is because I had no faith OpenERP snapshot
isolation SQL would scale easily enough for the size of the website
(possibly dozens of thousands of logged users interacting with data, hard
to predict yet), I built the framework in such a way that I can shard the
data over several independent OpenERP that feed the same SolR bigdata. In
my case one OpenERP per city or group of cities (synch'ed by conf
management devops then).

If you think about a SolR based REST catalog, please contact me as this
something I'm highly interested in for the future.



> I’ve forked solerp (my github account is gorghoa), and will read it and
> evaluate it against my needs very soon.
>

Cool!

I apologize for the current lack of documentation. But you can get an idea
on how to use it with this example for synchronizing products:
https://github.com/akretion/solerp/blob/master/solerp/product.py

You also need to set up the right SolR schema. My philosophy in Solerp has
been to be the more generic possible out of the box so OpenERP objects have
some reflexive way to map themselves to SoLR fields with a way to
denormalize hierachies into a SolR noSQL flat collection: include m2o and
denormalize o2m and m2m optionally. That default processing assumes some
dynamic fields in your SolR schema such as *_s for strings, *_i for
integers... In a real application you typically override the default
serialization to add a few extra fields of your own.


Regards, let me know how it goes with my connector if you use it. Contribs
appreciated.


-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 2516 2954
www.akretion.com

Follow ups

References