chat.freenode.net #tryton log beginning Fri Mar 25 00:00:01 CET 2011 | ||
-!- elbenfreund1(~elbenfreu@p54B95D32.dip.t-dialin.net) has joined #tryton | 01:22 | |
-!- FWiesing(~franz@mail.tryton.at) has left #tryton | 01:46 | |
-!- heg(~heg@dyn.83-228-214-133.dsl.vtx.ch) has joined #tryton | 02:17 | |
-!- gremly(~gremly@200.106.202.91) has joined #tryton | 02:20 | |
-!- serpent213(~digger@teralink.net) has joined #tryton | 03:57 | |
-!- cheche(cheche@46.25.80.67) has joined #tryton | 04:00 | |
-!- XeBa(~SeBas@host60.190-226-68.telecom.net.ar) has joined #tryton | 04:00 | |
-!- marga(~marga@nereida.gnuservers.com.ar) has joined #tryton | 04:00 | |
-!- heg(~heg@dyn.83-228-214-133.dsl.vtx.ch) has joined #tryton | 04:45 | |
-!- silverfox1971(~sysadmin0@office.delfi2000.ru) has joined #tryton | 05:05 | |
-!- heg(~heg@dyn.83-228-214-133.dsl.vtx.ch) has joined #tryton | 05:10 | |
-!- digitalsatori(~tony@116.233.240.178) has joined #tryton | 05:10 | |
-!- Vladimirek(~vladimir@adsl-dyn88.91-127-104.t-com.sk) has joined #tryton | 05:16 | |
-!- yangoon(~mathiasb@p549F27DD.dip.t-dialin.net) has joined #tryton | 05:18 | |
-!- okko(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton | 07:24 | |
-!- enlightx(~enlightx@static-217-133-61-144.clienti.tiscali.it) has joined #tryton | 07:52 | |
-!- trifon(~trifon@p548C516B.dip.t-dialin.net) has joined #tryton | 07:57 | |
-!- plantian(~ian@c-67-169-72-36.hsd1.ca.comcast.net) has joined #tryton | 08:07 | |
-!- predatell(~werty@195.189.234.248) has joined #tryton | 08:14 | |
-!- udono(~udono@ip-62-143-253-84.unitymediagroup.de) has joined #tryton | 08:32 | |
-!- Timitos(~kp@88.217.184.172) has joined #tryton | 09:06 | |
-!- Mayank(~MnzNotebu@61.16.156.123) has joined #tryton | 09:16 | |
-!- ecarreras(~under@unaffiliated/ecarreras) has joined #tryton | 09:19 | |
-!- nicoe(~nicoe@15.74-247-81.adsl-dyn.isp.belgacom.be) has joined #tryton | 09:20 | |
-!- okko(~okko@62.58.29.41) has joined #tryton | 09:20 | |
-!- curlynostrill(~curlynost@96.57.28.108) has joined #tryton | 09:25 | |
-!- digitalsatori(~tony@116.233.240.178) has joined #tryton | 09:31 | |
-!- paepke(~paepke@pD9545811.dip0.t-ipconnect.de) has joined #tryton | 09:42 | |
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton | 09:53 | |
-!- bechamel(~user@cismwks02-virtual1.cism.ucl.ac.be) has joined #tryton | 10:09 | |
-!- trifon_(~trifon@p548C7C83.dip.t-dialin.net) has joined #tryton | 10:22 | |
-!- ikks_(~ikks@190.158.112.7) has joined #tryton | 11:05 | |
-!- tony_(~tony@116.233.240.178) has joined #tryton | 11:32 | |
cedk | yangoon: is it you who has wrote a script to generate translation file for country? | 11:42 |
---|---|---|
yangoon | cedk: yes | 11:46 |
yangoon | isn't it anywhere in codereview or tracker? | 11:47 |
cedk | yangoon: because there is this issue https://bugs.tryton.org/roundup/issue1902 | 11:47 |
cedk | and I'm wondering if we could use it to generate those new translations | 11:48 |
yangoon | cedk: I don't know if subdivisions are in iso-codes | 11:48 |
cedk | yangoon: they come from the module pycountry which uses the ISO | 11:49 |
yangoon | cedk: yes, the base is iso-country from debian | 11:50 |
yangoon | cedk: http://codereview.appspot.com/820043 | 11:50 |
yangoon | cedk: https://bugs.tryton.org/roundup/issue1482 | 11:51 |
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton | 11:52 | |
cedk | yangoon: ok I think we should put it in country module under scripts | 11:53 |
cedk | yangoon: and update it to translate also the subdivision | 11:53 |
-!- trifon_(~trifon@p548C4AC5.dip.t-dialin.net) has joined #tryton | 11:56 | |
yangoon | cedk: phone | 12:06 |
yangoon | yes, good idea, same for currency | 12:06 |
yangoon | just now short in time, bbl | 12:06 |
-!- pjstevns(~pjstevns@a83-163-46-103.adsl.xs4all.nl) has joined #tryton | 12:20 | |
-!- enlightx(~enlightx@dynamic-adsl-94-34-234-210.clienti.tiscali.it) has joined #tryton | 12:32 | |
-!- hoRn(~chatzilla@dslb-094-222-141-034.pools.arcor-ip.net) has joined #tryton | 13:19 | |
-!- silverfox1971(~sysadmin0@office.delfi2000.ru) has left #tryton | 13:31 | |
-!- lem0na(~lem0na@95.87.233.210) has joined #tryton | 13:40 | |
-!- tony_(~tony@116.233.240.178) has joined #tryton | 13:53 | |
-!- chrue(~chrue@host-091-097-067-158.ewe-ip-backbone.de) has joined #tryton | 15:21 | |
-!- nicoe_(~nicoe@42.225-247-81.adsl-dyn.isp.belgacom.be) has joined #tryton | 15:38 | |
-!- Vladimirek(~vladimir@adsl-dyn88.91-127-104.t-com.sk) has joined #tryton | 16:15 | |
-!- nicoe(~nicoe@42.225-247-81.adsl-dyn.isp.belgacom.be) has joined #tryton | 16:37 | |
-!- zodman(~andres-va@foresight/developer/zodman) has joined #tryton | 16:49 | |
-!- Mayank(~MnzNotebu@122.161.219.190) has joined #tryton | 16:59 | |
-!- nicoe(~nicoe@42.225-247-81.adsl-dyn.isp.belgacom.be) has joined #tryton | 17:04 | |
-!- paepke(~paepke@pD954569B.dip0.t-ipconnect.de) has joined #tryton | 17:11 | |
-!- elbenfreund(~elbenfreu@p54B95D32.dip.t-dialin.net) has joined #tryton | 17:32 | |
-!- okko(~okko@62.58.29.41) has joined #tryton | 17:33 | |
-!- paepke(~paepke@pD954569B.dip0.t-ipconnect.de) has joined #tryton | 18:20 | |
zodman | hi! | 18:28 |
zodman | someone knows if trytond depends of genshi ? | 18:28 |
cedk | zodman: it depends because it depends of relatorio which dependsof genshi | 18:29 |
zodman | ok ok | 18:29 |
zodman | cedk: tnx i updating to last tryton on foresight linux :) | 18:29 |
cedk | zodman: indeed we use genshi filter in report.py | 18:29 |
zodman | ok ok np! | 18:30 |
cedk | zodman: dependencies are in the setup.py | 18:30 |
zodman | ok cedk foresightlinux detect dependencies automatic. Ok i take a look the setup.py tnx! | 18:31 |
-!- FWiesing(~franz@mail.tryton.at) has joined #tryton | 18:54 | |
udono | nicoe: It seems that tryton-users.svg is missing on tip? | 18:55 |
udono | btw,hi | 18:56 |
nicoe | hello | 18:56 |
nicoe | did you update to the last version ? | 18:56 |
nicoe | Cedric made a patch renaming it a few days ago | 18:56 |
nicoe | udono: it has been renamed to tryton-party | 18:58 |
udono | nicoe: I thought I did it. Let me check... | 18:59 |
udono | nicoe: ugs... forget to hg up ... | 19:00 |
udono | nicoe: thanks! | 19:00 |
nicoe | you're welcome | 19:00 |
-!- nicoe_(~nicoe@42.225-247-81.adsl-dyn.isp.belgacom.be) has joined #tryton | 19:48 | |
-!- plantian(~ian@c-67-169-72-36.hsd1.ca.comcast.net) has joined #tryton | 19:49 | |
-!- Timitos(~kp@88.217.184.172) has left #tryton | 20:39 | |
-!- Mayank(~beakkon@122.161.219.190) has joined #tryton | 21:23 | |
-!- sharoon(~sharoon@173-9-190-190-miami.txt.hfc.comcastbusiness.net) has joined #tryton | 21:52 | |
sharoon | hi everybody, we are working on the e-commerce problem and we are hitting the "unknown unknowns" issue and our alternatives are the infamous EAV or Schemaless NoSQL databases | 21:54 |
cedk | sharoon: what is "unknown unknowns" issue? | 21:56 |
sharoon | i remember a discussion in the IRC between cedk paepke bechamel yangoon on using MongoDB / CouchDB as a backend for tryton | 21:56 |
sharoon | cedk: consider the example of a company which sells books and furniture | 21:57 |
sharoon | cedk: the attributes on product for books are going to be different from the attributes on furniture | 21:57 |
sharoon | cedk: this bloats to several thousand attributes when you have many different kind of attributes | 21:58 |
sharoon | s/attributes/products | 21:58 |
sharoon | cedk: the possible ways to implement this are: | 22:01 |
sharoon | 1. Keep expanding the table by _inherit (slows downt he table and limitation of 1600 columns) | 22:01 |
sharoon | 2. Use _inherits - same issues as above and more cumbersome to manage views and will introduce lot of joins and nested _inherits is not supported | 22:01 |
sharoon | 3. Use EAV (Entity attribute value) - Difficult to manage, SQL joins etc | 22:01 |
sharoon | 4. Use two storages. The main data in product.product and all supplementary as schemaless object in a NoSQL database | 22:01 |
cedk | sharoon: I don't trust in EAV model | 22:02 |
sharoon | cedk: Glad that you dont.... i tried EAV and it sucks ;) | 22:02 |
cedk | sharoon: and I would like to understand what are those attributes? | 22:02 |
sharoon | cedk: we also have example of magento | 22:02 |
sharoon | cedk: Eg. in case of book. ISBN, Editor, Edition, Author, Publisher | 22:03 |
cedk | sharoon: did you read http://thebuild.com/blog/2011/02/25/10-ways-to-kill-performanc/ | 22:03 |
sharoon | cedk: reading now | 22:03 |
cedk | sharoon: for me your example must be solved by creating a new Model that inherit product | 22:04 |
cedk | I really trust in schema :-) | 22:05 |
sharoon | cedk: but imagine the same company sells cameras, the new attributes will be like BatteriesIncluded, DisplaySize, BatteryType, OpticalSensorResolution, OpticalZoom etc etc | 22:07 |
sharoon | so as the types of product increases - so will these attributes | 22:08 |
cedk | sharoon: and what is the problem? | 22:08 |
sharoon | cedk: using _inherit - this will keep increasing the no of columns in the DB | 22:08 |
sharoon | Table | 22:08 |
cedk | sharoon: every product that shares the same attributes (properties) will be in their specific table | 22:08 |
cedk | sharoon: managing tables is what DB is about | 22:09 |
sharoon | cedk: that would be using _inherits ? | 22:09 |
cedk | sharoon: yes | 22:10 |
sharoon | cedk: that is possible when the problem is "known unknows" not "unknown unknowns" | 22:10 |
cedk | sharoon: don't understand those quotes | 22:10 |
sharoon | cedk: if you know before hand that the customer is gonna sell cameras and books we can design for both | 22:11 |
sharoon | that is known (columns) unknown (values) | 22:11 |
sharoon | but often the case is unknown (columns) unknowns (values) | 22:12 |
cedk | sharoon: I don't think in users defining schema | 22:12 |
cedk | it is the best way to kill performence, logic and rational ... | 22:13 |
sharoon | cedk: its the "hot" feature eg. Magento, Virtuemart | 22:13 |
cedk | sharoon: feature like this are not useful indeed, what can you do with unknonw things? | 22:14 |
cedk | you can do nothing as you don't know | 22:14 |
cedk | sharoon: expect perhaps just redisplay it like it was encoded | 22:14 |
sharoon | cedk: hmm, it is what makes magento the popular system it is..... custom attributes is everythng | 22:15 |
sharoon | cedk: for example you may want to compare a product to product | 22:15 |
cedk | so the simple way will be to store it in a format XML, JSON or whatever in a varchar columns | 22:15 |
sharoon | cedk: a blob ? | 22:15 |
cedk | sharoon: you can not compare "apples and pears" (don't know if it is English :-) | 22:16 |
cedk | sharoon: yes a blob as it is unstructured data | 22:16 |
plantian | *apples and oranges | 22:16 |
sharoon | cedk: exactly, so if you need to compare one camera with another camera, you need to do it with its own attributes | 22:16 |
sharoon | cedk: which is why maintaining its values distinctly is required | 22:17 |
sharoon | cedk: and that is where a XML, JSOn storage will fail | 22:17 |
cedk | sharoon: which is why it is better to have it in a table (with schema) | 22:17 |
sharoon | cedk: you will not be able to search like megapixels = 10 | 22:17 |
plantian | I think extensive searching and browsing of products might be outside the realm of Tryton and connecting tryton products with another model outside of tryton might be better. | 22:18 |
cedk | sharoon: the fastest way to solve this search is having a columns megapixels with an index | 22:19 |
cedk | plantian: not completly sure but it is a possibility | 22:19 |
cedk | plantian: but I still think it is smarter to have a good database schema | 22:20 |
sharoon | cedk: back to the same question - what happens when the number of such attributes is really high | 22:20 |
cedk | sharoon: it is not a problem as it is in separate tables | 22:21 |
sharoon | cedk: looking at a design doc before me each product type has about 10 attributes each and they will be adding product types in the future | 22:21 |
sharoon | cedk: are you sure you can extend (product.product) using _inherits when it already extends from product.template with _inherits ? | 22:21 |
cedk | sharoon: it should but I think I fill a bug about search | 22:22 |
cedk | sharoon: and even, it is not required to have _inherits | 22:22 |
cedk | sharoon: _inherits is just to show a merge of the 3 tables | 22:23 |
sharoon | cedk: ok, so what is the alternative ? | 22:23 |
cedk | sharoon: the alternative to what? | 22:23 |
sharoon | cedk: u mentioned that it is not required to have _inherits? | 22:24 |
cedk | sharoon: it is just a many2one to product | 22:24 |
cedk | so you have your products in product_product and you store into the camera table the attributes for camera and just link it to the corresponding product | 22:25 |
sharoon | cedk: yes, this works and is ideal - but any idea on what to do when the column types is also not known prior ? | 22:26 |
cedk | sharoon: blob | 22:26 |
sharoon | cedk: :( search limitations then | 22:27 |
cedk | sharoon: you can not search for unknown | 22:28 |
sharoon | cedk: i really wish i could tell that to the customer :D (but as usual systems like magento does it... ) | 22:29 |
cedk | sharoon: and I read many times that magento has big performence issue because of that | 22:29 |
sharoon | cedk: thats because they suck in EAV | 22:30 |
sharoon | design pattern | 22:30 |
sharoon | cedk: what I am now thinking is go schemaless with MongoDB | 22:30 |
cedk | sharoon: there is not soo much way to store data: schema, EAV or blob | 22:30 |
sharoon | cedk: http://kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce/ | 22:30 |
cedk | sharoon: MongoDB == blob | 22:30 |
plantian | cedk: I think it has indexing and searching though right? | 22:31 |
cedk | sharoon: I know it is a shorcut but the way you think you will use MongoDB will be the same as having a blob in PostgreSQL | 22:32 |
sharoon | cedk: plantian: yes it has indexing, search and a lot more of other features | 22:32 |
cedk | plantian: yes but only the one you (DB manager) create | 22:32 |
cedk | plantian: with code | 22:32 |
sharoon | cedk: http://www.slideshare.net/sbeam/no-sql-no-problem-using-mongodb-in-ruby | 22:32 |
cedk | sharoon: and ? | 22:36 |
sharoon | cedk: plantian: any thoughts ? on a quick googling seems like schemaless DBs are replacing Old School EAV | 22:36 |
sharoon | cedk: this is scary - http://www.magentocommerce.com/wiki/2_-_magento_concepts_and_architecture/magento_database_diagram | 22:37 |
plantian | cedk, sharoon: I think it is a good compromise to store less important data outside of tryton in order to gain flexibility that Tryton cannot afford to give because it is full ERP. | 22:38 |
plantian | Although then its just one more system to maintain though so it is just another trade off. | 22:38 |
sharoon | i agree, and i think such a schemaless DB could also be used for storage of documents (ir.attachments) which are currently stored in the filesystem | 22:38 |
cedk | sharoon: why ? | 22:39 |
plantian | ha yeah that seems to have nothing to do with this | 22:39 |
sharoon | cedk: GridFS | 22:39 |
cedk | please don't fall in this buzz/fanboy trap where everybody wants to put NoSQL everywhere | 22:39 |
cedk | sharoon: until now the best way to store file is a filesystem | 22:40 |
plantian | sharoon: I agree with cedk's concern. | 22:40 |
plantian | *about traps | 22:40 |
sharoon | cedk: plantian: http://www.mongodb.org/display/DOCS/When+to+use+GridFS and http://www.tryton.org/~irclog/2010-08-26.log.html | 22:40 |
cedk | sharoon: I guess that FS of GridFS is for filesystem so no need to change anything to use it | 22:41 |
plantian | sharoon, cedk: I am interested in this extensible product problem though. I have been stuck with one type of product for a long time and need to get a real e-commerce solution going with products other than just Plants(the only product I have now). | 22:42 |
plantian | Right now, party because I moved from other system, I have plant products in another system and references between tryton and that system in order to have search/browse on the website and display product brochure information. | 22:43 |
sharoon | cedk: if there are large (**if**) the auto sharding etc could be of great use was what i thought :) i guess thats the way google big table works ? | 22:43 |
cedk | sharoon: yes flexible sharding is what is missing right now in trytond | 22:44 |
cedk | sharoon: need to find how to solved | 22:45 |
cedk | sharoon: but it should be not too complicated | 22:45 |
sharoon | cedk: one possibility would be making sure that the folders in the first level (from the digest) decide the sharding (based on mounts) | 22:46 |
cedk | sharoon: that's filesystem configuration (no for Tryton) | 22:47 |
cedk | sharoon: I mean the number os subfolder should be dynamic | 22:47 |
sharoon | cedk: got you :) but wont it be transparent to use something like mongodb... it will also take away the pain in the current system in the way we directy try to manage filesystems | 22:48 |
cedk | sharoon: if mongodb provide a filesystem interface | 22:49 |
sharoon | cedk: i guess it does... but I am just starting to use it. | 22:50 |
sharoon | cedk: so coming back to original question - what do you suggest ? | 22:51 |
cedk | sharoon: https://github.com/mikejs/gridfs-fuse | 22:51 |
sharoon | cedk: interesting | 22:51 |
sharoon | cedk: but I am not sure we need that ... we could use the native get and put ? | 22:52 |
cedk | sharoon: for me the best is table shema | 22:52 |
cedk | sharoon: filesystem is an well define API for file | 22:53 |
sharoon | cedk: what do you think of a ModelSchemaless which could be one of the ancestors/bases of a tryton object in join with ModelStorage ? | 22:53 |
cedk | sharoon: so we use it | 22:53 |
sharoon | cedk: i agree abt the file storage.... this is about the attribute problem | 22:53 |
cedk | sharoon: I don't think it is good | 22:53 |
cedk | sharoon: I'm more and more thinking about merging ModelStorage and ModelSQL | 22:53 |
cedk | sharoon: because any other data storage will be outside the transaction which is really bad for "ERP" | 22:54 |
sharoon | cedk: thats not a bad idea though .... we discussed it once | 22:54 |
cedk | and more over all the Model schema is linked to RDBMS | 22:54 |
sharoon | cedk: agree on that and we cant have any object being purely schemaless | 22:55 |
sharoon | cedk: it could be "Not Only SQL" | 22:55 |
sharoon | cedk: we use Schema for all regular information | 22:55 |
sharoon | cedk: and all extra attributes etc use the Schemaless ? | 22:55 |
cedk | sharoon: so you can not use MongoDB to solve your issue of schemaless data | 22:56 |
sharoon | cedk: MongoDB alone is not a solution, it has to be used along with ModelSQL even if I have to use it | 22:56 |
cedk | sharoon: so I don't see the benefit | 22:56 |
cedk | we agree that the paradigm of Tryton is schema ? | 22:57 |
sharoon | cedk: use both systems for what they are good at: ModelSQL for the webll defined schema we have and No(t only)SQL for less defined Schemaless data | 22:57 |
sharoon | cedk: yes | 22:57 |
cedk | sharoon: so you can not use Tryton with schemaless paradigm | 22:58 |
sharoon | cedk: :( I have to search for more solutions then... please do let me know if you find something interesting which could address the problem | 22:59 |
cedk | sharoon: and I repeat a schemaless solution will be the same as storing data in blob | 22:59 |
cedk | with just some faclilities for developpers | 22:59 |
sharoon | cedk: i am now considering the Blob also with a function field and allow search like the new search API bechamel proposed | 23:00 |
cedk | sharoon: you can store data in a format that allow to make some search easily | 23:01 |
sharoon | cedk: easiest i guess would be JSON | 23:02 |
cedk | sharoon: like: <attribute name>:<value>,... | 23:02 |
cedk | sharoon: not sure JSON will be the best | 23:02 |
sharoon | cedk: ok | 23:02 |
cedk | sharoon: here you need to store a list of couples | 23:02 |
sharoon | cedk: the value could be struct/list | 23:03 |
cedk | sharoon: by the way, PostgreSQL has a list column type | 23:03 |
cedk | sharoon: http://www.postgresql.org/docs/8.4/static/arrays.html | 23:04 |
sharoon | cedk: checking | 23:04 |
cedk | sharoon: not sure if it is a good idea | 23:05 |
sharoon | cedk: i think i have to try prototypes of both | 23:05 |
sharoon | cedk: also any ideas on how we could have dynamic views without affecting performance ? | 23:06 |
sharoon | cedk: one example we already have is the analytic accounts way of doing it | 23:06 |
cedk | sharoon: yes but at the end it is static view | 23:07 |
cedk | sharoon: the view is only generated on the fly | 23:07 |
sharoon | cedk: yeh true | 23:07 |
cedk | sharoon: doesn't seem that SQLite got array type | 23:09 |
cedk | sharoon: why not a kind of structured text format | 23:09 |
sharoon | cedk: will have to investigate, but would prefer to depend on standards | 23:10 |
sharoon | i am told "oracle" has some kind of XML field which does allow search, xpath for use in such cases | 23:11 |
cedk | sharoon: not sure it will have good perf but any blob will not have | 23:13 |
sharoon | cedk: agree | 23:13 |
sharoon | cedk: i will put whatever i develop to code review and lets see if you find it useful | 23:14 |
plantian | sharoon: Will you be searching the arbitrary columns of products IN tryton or on e-commerce site? | 23:14 |
sharoon | plantian: mostly from e-commerce site - like filter all cameras at 10 MP | 23:15 |
plantian | sharoon: Seems that you wouldn't need/use tryton search capabilities in that case. Would website interface directly query trytond? | 23:16 |
sharoon | plantian: yes | 23:16 |
sharoon | plantian: would be more like, search db.things.find( { x : 3, y : "foo" } ); get the product_id and return all records with the ids in the ids | 23:18 |
sharoon | returned by the NoSQL | 23:18 |
plantian | sharoon: Why not just store all you need in nosql then and not query trytond at all until sales are made ? | 23:19 |
sharoon | plantian: prices, pricelists, stock availability | 23:19 |
plantian | sharoon: Yes, I guess I kind of cache those now into another system for website to access. I am worried about performance problems caused by ERP overhead. | 23:21 |
plantian | sharoon: Are you going to develop e-commerce from scratch ? | 23:22 |
sharoon | plantian: i have done that already | 23:22 |
sharoon | plantian: now its developing advanced features like this one :) | 23:23 |
plantian | sharoon: Performance is okay? | 23:23 |
plantian | sharoon: I am interested in solution because I have some mutant solution right now that requires batches of things to be sent back and forth between systems(one of them tryton). | 23:24 |
sharoon | plantian: its fine, we did some load testing and we avoid direct hits to DB for readonly requirement by use of Cache | 23:24 |
sharoon | Memcached to be precise | 23:24 |
plantian | sharoon: How many products and how many inventory locations ? | 23:25 |
sharoon | 1 inventory location and 400 products | 23:25 |
sharoon | 4000 | 23:25 |
sharoon | thats small we know | 23:26 |
sharoon | we are now on a bigger project with about 30 stores and 200 K products | 23:26 |
plantian | I think inventory location is hardest part but also dynamic price calculation is difficult. | 23:26 |
sharoon | plantian: yes, but dynamic calculation must always be cached | 23:27 |
plantian | I only have two warehouses but each warehouse has many locations inside it. | 23:27 |
plantian | sharoon: Yeah I use memcached on the site but not for caching product information. Its good to know you have gotten a direct interface to work, maybe I will try to move everything to trytond one day. | 23:28 |
plantian | sharoon: I had to add another type of list to determine if products are salable at different stores, have you needed to do that too ? | 23:30 |
sharoon | plantian: we implemented a logic where each website could have categories enabled and then selectively disable products if required | 23:30 |
plantian | sharoon: Nice, I called them salable lists and they are modeled after price list. I had to add another level of flexibility though and have product store salability and product store pricing to be used as the basis for price lists and salable lists. | 23:33 |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!