openerp-brazil-team team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Descupla pelo email que foi assim mesmo cortado.
Na verdade aquele commit é de Septembro de 2008, entao se for regressao, nao
é recente.
Mas ja vi que colocando um 80 com limite là no name_search por padrao
resolve o problema.
Nao sei se vamos ter que sobre carregar name_search no NCM, estou achando
muito estranho se nao tem mais paginaçao por padrao, apenas onde e
sobrecarregado.

Tou continuindo a investigar o assunto....


Raphaël Valyi
http://www.akretion.com


2009/9/10 Raphaël Valyi <rvalyi@xxxxxxxxx>

> Nada dos ids nao! Isso é consequencia do commit #1063
> (id hmo@xxxxxxxxxxx-20080909073454-48dwp8jhmllkzxzl ) feita no servidor
> pela Tiny mesmo dia 9 de Setembro!
> Os caras tiraram o limite padrao de 80 no methodo name_search.
>
> Acontece que em muito outros lugares, tipos account.account, stock.stock o
> name_search esta sobrecaregado, e continuao com 80 por padrao, entao
> continua funcionando.
>
> Mais eu acho que isso foi besteira. Quando a gente falava em regresssoes,
> ai que esta!
> Vou ver com a Tiny ess
>
>
>
> 2009/9/10 Raphaël Valyi <rvalyi@xxxxxxxxx>
>
> Ola,
>>
>> estou tentando entender porque o campo ncm_id no objeto product.product do
>> modulo l10n_br (branch Launchpad do projeto) é devagar assim e carrega todos
>> os records. Ainda nao entendi,
>> so vejo que:
>> >>> import xmlrpclib
>> >>> s=sock.execute('brasil', 1, "admin", 'l10n_br.ncm', 'name_search', '',
>> [], 'ilike', {'lang': u'en_US', 'active_ids': [109], 'tz': False,
>> 'active_id': 109})
>> >>> len(s)
>> 9736
>>
>> Normalmente, para qualquer outro objeto o resultado e paginado com grupos
>> de apenas 80 records por padrao. Com l10n_br.ncm nao é, esta me deixando
>> malouco porque acaba sendo muito devagar e abala a ergonomia claro.
>>
>> Entao dei uma ollhada em l10n_br/l10n_br_data.xml e vi que tinha ums
>> problemas com os ids dos records pelo menos.
>> Esses ids sao igual dos dos "fixtures" no Ruby on Rails, nao sao ids de
>> tabelas, e um sitema inteligente que permite atualisaçoes dos records do
>> OpenERP na fase de implementaçao ou nas migraçoes de maintenance.
>> Esses ids acabam na tabela ir_model_data.
>>
>> Entao, noa pode ser que dois recods tem o mesmo ids (senao um replaça o
>> outro). Mas nequele arquivo so tem isso, procura id="1"
>> tem monte de objetos diferentes com mesmo ids.
>> Tambem, apenas re-lembro tem um blueprint ai para que essses dados planos
>> todos vao para formato CSV e nao XML porque XML e muito mais devagar e
>> pesada, quando nao tem estrutura como no caso do NCM o outros, nao é
>> preciso. Apenas vai servir para a planilha de contas.
>>
>> Bom, isso é bobagem, vamos acabar com esses ids, pelo menos prefixamos
>> eles diferentementes.
>>
>> Ainda nao sei se o problema com a popup do many3one do ncm_id tem a ver
>> com esses problemas de ids, mas por enquanto nao achei pista melhor.
>>
>>
>> Vamos là, outras informaçoes depois. Queria botar a planilha de conta BR
>> tambem, mas nao podemos deixar esses probemas de ids e o ncm devagar assim.
>>
>>
>>
>> Raphaël Valyi
>> http://www.akretion.com
>>
>
>