@Guewen,
just a note to tell that a per product export is how I
implemented https://github.com/akretion/solerp/tree/master/solerp
[1] 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 [2], a
technology built at Standford university and now powering many other
US universities http://projecthydra.org/ [3]
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 [4]) 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’v
r>
I apologize for the current lack of documentation. But you can get
an idea on how to use it with this exam
ronizing products:
https://github.com/akretion/solerp/blob/master/solerp/product.py [5]
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 [6]
+55 21 2516 2954
www.akretion.com [7]
Links:
------
[1] https://github.com/akretion/solerp/tree/master/solerp
[2] https://github.com/projectblacklight/blacklight
[3] http://projecthydra.org/
[4] https://github.com/plataformatec/devise
[5] https://github.com/akretion/solerp/blob/master/solerp/product.py
[6] http://twitter.com/#!/rvalyi
[7] http://www.akretion.com/
