Bom dia!

        O Google Groups diz que o grupo PyGtk-Brasil [1] não existe mais,
alguém sabe de alguma coisa?

[1] http://groups.google.com/group/pygtk-brasil


[]'s
               Junior Polegato

2010/2/2 Alexandre Fiori <fiorix@...>

>
>
> talvez não seja bom que fique tão popular, pois pode acontecer o mesmo que
> já vimos com php;
> hoje em dia os profissionais são ruins e as empresas pagam uma mixaria.
>
> 2010/2/2 Vinicius Assef <viniciusban@... <viniciusban%40gmail.com>>
>
Alexandre.

Tome mais cuidado quando escrever algo do tipo "*hoje em dia os
profissionais são ruins*", tendo feito uma referência a uma outra linguagem,
no caso o PHP. Há pessoas que programam tanto em PHP como Python.

Não é um comentário nada educado, e que não agrega para a comunidade Python.


>
> >
> >
> > Espírito Santo, idem. :-(
> >
> > --
> > Vinicius Assef.
> >
> > 2010/2/2 George Ribeiro <george.rib@...
<george.rib%40gmail.com><george.rib%
> 40gmail.com>>:
>
> >
> > > E no Ceará, aqui o mercado anda fraco ainda.
> > >
> > > Em 1 de fevereiro de 2010 19:07, Magno Junior
<is.magnojr@...<is.magnojr%40gmail.com>
> <is.magnojr%40gmail.com>>
>
> > escreveu:
> > >> É legal ver que ultimamente tem muita procurar por desenvolvedores
> > python na
> > >> lista.
> > >> Parece que o mercado ta crescendo mesmo,
> > >> mas gostaria de ver isso aqui no Maranhão.
> > >>
> > >> Em 1 de fevereiro de 2010 18:46, hcarvalhoalves
> > >> <hcarvalhoalves@... <hcarvalhoalves%40gmail.com><hcarvalhoalves%
> 40gmail.com>>escreveu:
>
> > >>
> > >>>
> > >>>
> > >>> Procuramos profissional com experiência em desenvolvimento web
> > >>> utilizando Python e Django para trabalhar no desenvolvimento de
> > >>> produto voltado a usuário final, em empresa de ambiente casual,
> > >>> localizada no Brooklin, São Paulo.
> > >>>
> > >>> Responder em privado com currículo.
> > >>>
> > >>>
> > >>
> > >>
> > >> [As partes desta mensagem que não continham texto foram removidas]
> > >>
> > >>
> > >>
> > >> ------------------------------------
> > >>
> > >> ,----------------------------------------------------------.
> > >> | Antes de enviar um e-mail para o grupo leia: |
> > >> | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar |
> > >> | E se você é usuário do BOL lembre-se de cadastrar o |
> > >> | e-mail do grupo na lista branca do seu sistema anti-spam. |
> > >> `----------------------------------------------------------´Links do
> > Yahoo! Grupos
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > > --
> > > George Ribeiro
> > > Desenvolvedor Web Python/Django
> > > Coordenador de Projetos - Empresa Júnior Computação
> > > Sobral/CE
> > >
> > >
> > > ------------------------------------
> > >
> > > ,----------------------------------------------------------.
> > > | Antes de enviar um e-mail para o grupo leia: |
> > > | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar |
> > > | E se você é usuário do BOL lembre-se de cadastrar o |
> > > | e-mail do grupo na lista branca do seu sistema anti-spam. |
> > > `----------------------------------------------------------´Links do
> > Yahoo! Grupos
> > >
> > >
> > >
> >
> >
>
> --
> Ship ahoy! Hast seen the While Whale?
> - Melville's Captain Ahab
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>


[As partes desta mensagem que não continham texto foram removidas]

Fiz alguns teste com as sugestões do Alison e os resultados são bem
promissores, principalmente com blocos de 50kB. A taxa de transferência
melhorou substancialmente. Quanto tiver mais tempo testo em uma rede
melhor controlada para certificar os resultados.

O reporthook não conhecia, vou dar uma olhada em breve.

Valeu...

   Nilton Volpato wrote:
>
> 2010/2/8 Rudson Alves <rudsonalves@...
> <mailto:rudsonalves%40yahoo.com.br>>
>
> > Fiz uma rotina para fazer download de arquivos na internet usando o
> urllib,
> > mas estou tendo duas dificuldades as quais não sei ainda como resolver.
> >
>
> Você tem que ler em blocos. Algo como 8K de cada vez. Caso contrário o
> desempenho vai ser muito ruim mesmo.
>
> Mas note que já existe a função urlretrieve
> http://docs.python.org/library/urllib.html#urllib.urlretrieve
> <http://docs.python.org/library/urllib.html#urllib.urlretrieve> da urllib
> padrão, que salva o conteúdo para um arquivo. Além disso você pode usar o
> argumento "reporthook" para mostrar um barra de progresso em modo
> texto, se
> quiser. No pypi tem uma muito boa. :)
>
> Abraços,
> -- Nilton
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>



[As partes desta mensagem que não continham texto foram removidas]

2010/2/8 Rudson Alves <rudsonalves@...>

> Fiz uma rotina para fazer download de arquivos na internet usando o urllib,
> mas estou tendo duas dificuldades as quais não sei ainda como resolver.
>

Você tem que ler em blocos. Algo como 8K de cada vez. Caso contrário o
desempenho vai ser muito ruim mesmo.

Mas note que já existe a função urlretrieve
http://docs.python.org/library/urllib.html#urllib.urlretrieve da urllib
padrão, que salva o conteúdo para um arquivo. Além disso você pode usar o
argumento "reporthook" para mostrar um barra de progresso em modo texto, se
quiser. No pypi tem uma muito boa. :)

Abraços,
-- Nilton


[As partes desta mensagem que não continham texto foram removidas]

Bom, eu não vou discutir, mas discordo de você :)

Em 8 de fevereiro de 2010 20:05, Alexandre Fiori <fiorix@...> escreveu:
>
>
>
> pô, é completamente diferente
> os rdbms possuem muitas características diferentes, mas essas
> diferenças são "comandos" na linguagem sql, ou seja, na "string" que
> interage com o banco.
> ainda, no python, (novamente, sorry) o pep-249 padroniza a API de
> todos os rdbms.
>
> a grosso modo, os ORMs servem pra criar uma query string, e nada mais.
>
> porém, não quero de modo algum desencorajar o desenvolvimento de um
> "opl". apenas reforço que "minha opinião pessoal" é que "hoje" não
> vale a pena por ser pouco provável que facilite a programação, ao
> invés de complicar e deixar tudo lento pelo overhead dessa camada
> extra.
>
> 2010/2/8 Marinho Brandao <marinho@...>:
>
> > Alexandre,
> >
> > se for seguir o seu raciocínio, então para quê existem ORMs?
> >
> > 1) Cada banco relacional possui sua variante do SQL e do padrão de DDL/DML
etc,
> > 2) Cada um deles possui uma forma de comunicação diferente
> > 3) Cada um deles possui uma forma de indexar e armazenar páginas próprias
> > 4) Já existem bibliotecas com o psycopg, MySQLdb, etc para implementar
> > as particularidades e comunicação de cada um
> >
> > Ou seja, porque não usar direto o psycopg? Pra que existem interfaces
> > como ODBC, JDBC, etc.?
> >
> > Veja, a gente precisa se lembrar de que relacional ou não relacional,
> > todos eles são REPOSITÓRIOS DE DADOS, e os dados que são direcionados
> > a eles geralmente vêm de uma classe de modelo. Ponto final.
> >
> > Ou seja: todos eles são formas diferentes de se armazenar dados que
> > estavam em objetos... ou seja:
> >
> > MAPEAMENTO OBJETO -> REPOSITORIO.
> >
> > Agora, sobre qual é o tipo do repositório, isso é questão pro adapter
> > (ou backend, como preferir) resolver, e ele provavelmente vai usar as
> > bibliotecas já existentes (psycopg, pymongodb, MySQLdb, etc) pra isso.
> >
> > Quanto aos backends de bancos NoSQL para Django, dê uma olhada no fonte
deles ;)
> >
> > Em 6 de fevereiro de 2010 23:07, Alexandre Fiori <fiorix@...>
escreveu:
> >>
> >>
> >>
> >> o que posso compartilhar aqui é o seguinte:
> >>
> >> alguns amigos que trabalham na boo-box.com, com o sistema em ruby, usaram
> >> couchdb e tiveram péssimas experiências. muito problema com desempenho e
> >> estabilidade - como vários crashes por dia em high-load.
> >>
> >> sobre bibliotecas de persistência, acho bem improvável que passem a
suportar
> >> "nosql" pois esses bancos não seguem uma linguagem comum como sql, que já
> >> não se enquadra no PEP 249 (python database api specification v2.0:
> >> http://www.python.org/dev/peps/pep-0249/)
> >>
> >> voltando ao assunto original desta thread, the é desempenho vs capacidade,
> >> posso compartilhar o seguinte:
> >>
> >> o maior sistema que já desenvolvi com python e rdbm era baseado em pgsql;
> >> mas antes, fiz diversos testes com mysql, sybase, firebird e até lucene -
> >> pois um dos requisitos era full-text search. o pgsql foi o que se comportou
> >> melhor, com cerca de 10 milhões de registros adicionados e removidos por
> >> dia, mantendo uma média de 250 milhões de registros constantes na base.
> >>
> >> usando sharding, dividindo read e write para máquinas diferentes, com 6
> >> máquinas (3 masters e 3 slaves), funcionou perfeito. a indexação é meio
> >> lenta, pois cada insert já indexava também os campos de busca por texto,
> >> usando "fast full-text search" - artigo do meu blog:
> >> http://fiorix.wordpress.com/2009/03/12/postgresql-fast-full-text-search/
> >>
> >> por fim, sobre nosql:
> >>
> >> tenho mantido dois "drivers" para bancos completamente diferentes, baseados
> >> em twisted, para redis e mongodb.
> >> http://github.com/fiorix/txredisapi
> >> http://github.com/fiorix/mongo-async-python-driver
> >>
> >> é impossível que essas APIs sejam padronizadas e enquadradas em algo como
> >> sqlalchemy, pois os métodos providos por esses bancos são totalmente fora
do
> >> padrão sql.
> >>
> >> ainda, vale lembrar que o mongodb (que é c++ e não c) permite acessar os
> >> registros através do filesystem, usando o gridfs:
> >>
> >> http://www.mongodb.org/display/DOCS/GridFS+Specification
> >> e um módulo REST pro nginx, que acessa o gridfs:
> >> http://github.com/mdirolf/nginx-gridfs
> >>
> >> a única limitação é que cada registro pode ter no máximo 4MB. além disso, o
> >> mongodb tem uma limitação de base máxima de 2.5GB em máquinas 32bit - já em
> >> máquinas 64bit o tamanho da base é ilimitada, e em ambos os casos ele é
> >> super rápido pois o acesso aos dados é feito por meio de mmap, onde o
kernel
> >> já se encarrega de fazer cache dos dados mais acessados.
> >>
> >> http://blog.mongodb.org/post/137788967/32-bit-limitations
> >>
> >> espero que ajude.
> >>
> >> abs
> >>
> >> AF
> >>
> >> 2010/2/6 Marinho Brandao <marinho@...>
> >>
> >> >
> >> >
> >> > Ha, e mais uma coisa...
> >> >
> >> > Uma coisa que andei falando recentemente na lista do Tornado e no
> >> > Twitter, mas falei também há uns 4 ou 5 anos quando entrei na
> >> > python-brasil:
> >> >
> >> > Eu sinto falta de uma biblioteca de persistência no Python *que não
> >> > seja presa* ao modelo ORM. De fato, as bibliotecas que eu conheço
> >> > razoavelmente (SQLAlchemy, Django e SQLObject) estão *muito* presas ao
> >> > relacional e à normalização. Chega a ser inviável adaptá-los a bancos
> >> > NoSQL.
> >> >
> >> > Eu já fiz uma OPF (que acho um nome mais razoável do que ORM) em
> >> > Delphi que era bem mais compatível com esse modelo, e se não fosse a
> >> > inviabilidade de reinventar a roda, eu faria uma semelhante no Python,
> >> > mas o fato é que hoje não é nada prático usar mais de um banco de
> >> > dados (de paradigmas diferentes) nas bibliotecas que eu conheço no
> >> > Python
> >> >
> >> > Só uma centavo a mais... :)
> >> >
> >> > Em 6 de fevereiro de 2010 19:13, Marinho Brandao
<marinho@...<marinho%40gmail.com>>
> >> > escreveu:
> >> >
> >> > > Oi Marco, boa noite
> >> > >
> >> > >> Aproveitando a mensagem do Luciano e essa discussão off-topic sobre
> >> > Banco de Dados...
> >> > >
> >> > > nem tão off assim :P
> >> > >
> >> > >> Gostaria da receber opinião do pessoal da lista para o seguinte
> >> > problema.
> >> > >>
> >> > >> Já faz algum tempo que participo do desenvolvimento de um sistema que
> >> > não usa Banco de Dados,
> >> > >> todas as informações são armazenadas em arquivos proprietários no
"file
> >> > system". O motivo
> >> > >> de usar essa abordagem é porque ainda não encontramos uma solução
viável
> >> > de banco de dados
> >> > >> para armazenar um grande volume de dados. Estou falando algo em torno
de
> >> > 60 milhöes de
> >> > >> registros sendo inseridos na base de dados por dia.
> >> > >
> >> > > vixi, isso é MUITA coisa... hehe :)
> >> > >
> >> > >> Atualmente estou começando a analisar bancos de dados orientados a
> >> > coluna
> >> > >> http://en.wikipedia.org/wiki/Column-oriented_DBMS (ouvi dizer que um
> >> > produto da HP está usando
> >> > >> o Sybase IQ que é um banco de dados orientado a coluna) para
> >> > armazenamento de grandes volumes
> >> > >> de dados). Confesso que Banco de Dados não é muito minha praia....
> >> > >>
> >> > >> Gostaria de receber opiniões das pessoas da lista a respeito desse
> >> > conceito de banco de dados ou
> >> > >> de algum outro modelo de armazenamento para grandes volumes de dados.
> >> > >>
> >> > >> Para não ficar tão distante do mundo Python, esse sistema foi todo
> >> > desenvolvido em Python.
> >> > >
> >> > > Olha, eu tenho tido experiência prática com o CouchDB e com o MongoDB.
> >> > > Nada no nível de 60 milhões de registros diários, mas as minhas
> >> > > opiniões sobre os dois estão assim:
> >> > >
> >> > > Sobre o CouchDB, estamos usando num sistema onde há mais de 4000
> >> > > instituições cadastradas e cada uma delas entra com suas informações,
> >> > > *mas* essas informações são peculiares de cada uma (imagine que uma
> >> > > universidade federal do Kansas possua informações que divergem por
> >> > > definição de uma escola de artes particular de Nova York, e assim por
> >> > > diante. O CouchDB é REST nativo e suporta persistência assíncrona.
> >> > >
> >> > > Sobre o MongoDB, estamos usando num aplicativo pequeno, desktop, que é
> >> > > instalado com instalador e em várias redes locais pequenas (de uma a 5
> >> > > máquinas cada). O desempenho do Mongo me pareceu superior, é muito
> >> > > fácil de instalar standalone, e às vezes lembra o memcache (ele tem um
> >> > > cache em memória na fronteira entre a comunicação e a persistência.
> >> > > Por outro lado, não tem REST nem persistência assíncrona (coisas que
> >> > > estão em desenvolvimento). Outra coisa peculiar do Mongo é que o BSON
> >> > > (formato semelhante ao JSON) é usado para filtro, map/reduce e o
> >> > > diabo, e às vezes é meio esquisito, com JavaScript e umas macros no
> >> > > meio da história.
> >> > >
> >> > > Resumindo, o CouchDB parece mais lento, porém mais elegante. O Mongo
> >> > > parece mais prático para trabalhar distribuído. E outra coisa: o
> >> > > CouchDB é Erlang e o MongoDB é C puro, ou seja...
> >> > >
> >> > > Bom, é isso o que eu tenho visto até aqui :)
> >> > >
> >> > > --
> >> > > Marinho Brandão (José Mário)
> >> > > http://marinhobrandao.com/
> >> > >
> >> >
> >> > --
> >> > Marinho Brandão (José Mário)
> >> > http://marinhobrandao.com/
> >> >
> >> >
> >>
> >> --
> >> Ship ahoy! Hast seen the While Whale?
> >> - Melville's Captain Ahab
> >>
> >> [As partes desta mensagem que não continham texto foram removidas]
> >>
> >>
> >
> >
> > --
> > Marinho Brandão (José Mário)
> > http://marinhobrandao.com/
> >
> >
> > ------------------------------------
> >
> > ,----------------------------------------------------------.
> > | Antes de enviar um e-mail para o grupo leia:              |
> > | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar  |
> > | E se você é usuário do BOL lembre-se de cadastrar o       |
> > | e-mail do grupo na lista branca do seu sistema anti-spam. |
> > `----------------------------------------------------------´Links do Yahoo!
Grupos
> >
> >
> >
>
> --
> Ship ahoy! Hast seen the While Whale?
> - Melville's Captain Ahab
>
>


--
Marinho Brandão (José Mário)
http://marinhobrandao.com/

usar wget via "system" é desnecessário.

http://twistedmatrix.com/documents/8.1.0/api/twisted.web.client.html#downloadPag\
e


2010/2/8 caio ariede <caio.ariede@...>:
> Aqui: http://unxutils.sourceforge.net/
>
> Se for algo simples, acho melhor não utilizar wget, pois criaria mais uma
> "dependência". A não ser que seja algum problema crítico relacionado a
> performance mesmo.
>
> Porém se for algo mais complexo, não vejo motivos para não utilizá-lo.
>
> Caio Ariede
> http://caioariede.com/
>
>
> 2010/2/8 Rafael Sierra <rafaeljsg14@...>
>
>>
>>
>> 2010/2/8 Henrique Baggio <hnrqbaggio@... <hnrqbaggio%40gmail.com>>:
>>
>> > 2010/2/8 @maltzsama <causbla@... <causbla%40gmail.com>>
>> >
>> >>
>> >>
>> >> Mas fazer a "gambiarra" de usar o wget dentro do python nao dificulta
>> >> uma possivel portabilidade de um *NIX para um windows ou ate um
>> >> celular, por exemplo? Não se torna mais facil realemnte fazer o que
>> >> ele esta fazendo ao nao incorporar o wget(Ferramenta caracteristica do
>> >> *nix)?
>> >>
>>
>> Com o cygwin você consegue instalar o wget no windows e usar de boa.
>>
>> Mas acredito que a melhor solução seria fazer uma especie de
>> {{{
>> import time
>> while True:
>> xpto.read(50*102.4) # 50KB
>> time.sleep(.1)
>> }}}
>>
>> Assim voce garante que vai ler ate 50KB/s :)
>>
>>
>> >
>> > Não sei como resolver no caso de um celular, mas existe uma
implementação
>> do
>> > Wget pro Windows. Não tenho o link à mão, mas uma busca simples no
Google
>> > encontra com certeza. Eu já testei e funcionou bem (Acho que as suites
>> que
>> > portam o Unix pro Windows como MinGW devem vir com um wget tb).
>> >
>> > Eu já trouxe essa dúvida uma vez pra lista e no fim achei que usar um
>> wget +
>> > subprocess não era não ruim assim pq não precisa reinventar a roda.
>> >
>> > E quanto aos problemas do Rudson, acho que tem mesmo a ver com o fato de
>> se
>> > procurar linhas num binário, mas posso estar falando bobogem.
>> >
>> >
>> > [As partes desta mensagem que não continham texto foram removidas]
>> >
>> >
>> >
>> > ------------------------------------
>>
>> >
>> > ,----------------------------------------------------------.
>> > | Antes de enviar um e-mail para o grupo leia:              |
>> > | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar  |
>> > | E se você é usuário do BOL lembre-se de cadastrar o       |
>> > | e-mail do grupo na lista branca do seu sistema anti-spam. |
>> > `----------------------------------------------------------´Links do
>> Yahoo! Grupos
>> >
>> >
>> >
>>
>> --
>> Rafael Sierra
>> http://blog.stiod.com
>>
>>
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>
> ------------------------------------
>
> ,-----------------------------------------------------------.
> | Antes de enviar um e-mail para o grupo leia:              |
> | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar  |
> | E se você é usuário do BOL lembre-se de cadastrar o       |
> | e-mail do grupo na lista branca do seu sistema anti-spam. |
> `-----------------------------------------------------------´Links do Yahoo!
Grupos
>
>
>



--
Ship ahoy! Hast seen the While Whale?
   - Melville's Captain Ahab

pô, é completamente diferente
os rdbms possuem muitas características diferentes, mas essas
diferenças são "comandos" na linguagem sql, ou seja, na "string" que
interage com o banco.
ainda, no python, (novamente, sorry) o pep-249 padroniza a API de
todos os rdbms.

a grosso modo, os ORMs servem pra criar uma query string, e nada mais.

porém, não quero de modo algum desencorajar o desenvolvimento de um
"opl". apenas reforço que "minha opinião pessoal" é que "hoje" não
vale a pena por ser pouco provável que facilite a programação, ao
invés de complicar e deixar tudo lento pelo overhead dessa camada
extra.

2010/2/8 Marinho Brandao <marinho@...>:
> Alexandre,
>
> se for seguir o seu raciocínio, então para quê existem ORMs?
>
> 1) Cada banco relacional possui sua variante do SQL e do padrão de DDL/DML
etc,
> 2) Cada um deles possui uma forma de comunicação diferente
> 3) Cada um deles possui uma forma de indexar e armazenar páginas próprias
> 4) Já existem bibliotecas com o psycopg, MySQLdb, etc para implementar
> as particularidades e comunicação de cada um
>
> Ou seja, porque não usar direto o psycopg? Pra que existem interfaces
> como ODBC, JDBC, etc.?
>
> Veja, a gente precisa se lembrar de que relacional ou não relacional,
> todos eles são REPOSITÓRIOS DE DADOS, e os dados que são direcionados
> a eles geralmente vêm de uma classe de modelo. Ponto final.
>
> Ou seja: todos eles são formas diferentes de se armazenar dados que
> estavam em objetos... ou seja:
>
> MAPEAMENTO OBJETO -> REPOSITORIO.
>
> Agora, sobre qual é o tipo do repositório, isso é questão pro adapter
> (ou backend, como preferir) resolver, e ele provavelmente vai usar as
> bibliotecas já existentes (psycopg, pymongodb, MySQLdb, etc) pra isso.
>
> Quanto aos backends de bancos NoSQL para Django, dê uma olhada no fonte deles
;)
>
> Em 6 de fevereiro de 2010 23:07, Alexandre Fiori <fiorix@...> escreveu:
>>
>>
>>
>> o que posso compartilhar aqui é o seguinte:
>>
>> alguns amigos que trabalham na boo-box.com, com o sistema em ruby, usaram
>> couchdb e tiveram péssimas experiências. muito problema com desempenho e
>> estabilidade - como vários crashes por dia em high-load.
>>
>> sobre bibliotecas de persistência, acho bem improvável que passem a
suportar
>> "nosql" pois esses bancos não seguem uma linguagem comum como sql, que já
>> não se enquadra no PEP 249 (python database api specification v2.0:
>> http://www.python.org/dev/peps/pep-0249/)
>>
>> voltando ao assunto original desta thread, the é desempenho vs capacidade,
>> posso compartilhar o seguinte:
>>
>> o maior sistema que já desenvolvi com python e rdbm era baseado em pgsql;
>> mas antes, fiz diversos testes com mysql, sybase, firebird e até lucene -
>> pois um dos requisitos era full-text search. o pgsql foi o que se comportou
>> melhor, com cerca de 10 milhões de registros adicionados e removidos por
>> dia, mantendo uma média de 250 milhões de registros constantes na base.
>>
>> usando sharding, dividindo read e write para máquinas diferentes, com 6
>> máquinas (3 masters e 3 slaves), funcionou perfeito. a indexação é meio
>> lenta, pois cada insert já indexava também os campos de busca por texto,
>> usando "fast full-text search" - artigo do meu blog:
>> http://fiorix.wordpress.com/2009/03/12/postgresql-fast-full-text-search/
>>
>> por fim, sobre nosql:
>>
>> tenho mantido dois "drivers" para bancos completamente diferentes, baseados
>> em twisted, para redis e mongodb.
>> http://github.com/fiorix/txredisapi
>> http://github.com/fiorix/mongo-async-python-driver
>>
>> é impossível que essas APIs sejam padronizadas e enquadradas em algo como
>> sqlalchemy, pois os métodos providos por esses bancos são totalmente fora
do
>> padrão sql.
>>
>> ainda, vale lembrar que o mongodb (que é c++ e não c) permite acessar os
>> registros através do filesystem, usando o gridfs:
>>
>> http://www.mongodb.org/display/DOCS/GridFS+Specification
>> e um módulo REST pro nginx, que acessa o gridfs:
>> http://github.com/mdirolf/nginx-gridfs
>>
>> a única limitação é que cada registro pode ter no máximo 4MB. além
disso, o
>> mongodb tem uma limitação de base máxima de 2.5GB em máquinas 32bit - já
em
>> máquinas 64bit o tamanho da base é ilimitada, e em ambos os casos ele é
>> super rápido pois o acesso aos dados é feito por meio de mmap, onde o
kernel
>> já se encarrega de fazer cache dos dados mais acessados.
>>
>> http://blog.mongodb.org/post/137788967/32-bit-limitations
>>
>> espero que ajude.
>>
>> abs
>>
>> AF
>>
>> 2010/2/6 Marinho Brandao <marinho@...>
>>
>> >
>> >
>> > Ha, e mais uma coisa...
>> >
>> > Uma coisa que andei falando recentemente na lista do Tornado e no
>> > Twitter, mas falei também há uns 4 ou 5 anos quando entrei na
>> > python-brasil:
>> >
>> > Eu sinto falta de uma biblioteca de persistência no Python *que não
>> > seja presa* ao modelo ORM. De fato, as bibliotecas que eu conheço
>> > razoavelmente (SQLAlchemy, Django e SQLObject) estão *muito* presas ao
>> > relacional e à normalização. Chega a ser inviável adaptá-los a bancos
>> > NoSQL.
>> >
>> > Eu já fiz uma OPF (que acho um nome mais razoável do que ORM) em
>> > Delphi que era bem mais compatível com esse modelo, e se não fosse a
>> > inviabilidade de reinventar a roda, eu faria uma semelhante no Python,
>> > mas o fato é que hoje não é nada prático usar mais de um banco de
>> > dados (de paradigmas diferentes) nas bibliotecas que eu conheço no
>> > Python
>> >
>> > Só uma centavo a mais... :)
>> >
>> > Em 6 de fevereiro de 2010 19:13, Marinho Brandao
<marinho@...<marinho%40gmail.com>>
>> > escreveu:
>> >
>> > > Oi Marco, boa noite
>> > >
>> > >> Aproveitando a mensagem do Luciano e essa discussão off-topic sobre
>> > Banco de Dados...
>> > >
>> > > nem tão off assim :P
>> > >
>> > >> Gostaria da receber opinião do pessoal da lista para o seguinte
>> > problema.
>> > >>
>> > >> Já faz algum tempo que participo do desenvolvimento de um sistema que
>> > não usa Banco de Dados,
>> > >> todas as informações são armazenadas em arquivos proprietários no
"file
>> > system". O motivo
>> > >> de usar essa abordagem é porque ainda não encontramos uma solução
viável
>> > de banco de dados
>> > >> para armazenar um grande volume de dados. Estou falando algo em torno de
>> > 60 milhöes de
>> > >> registros sendo inseridos na base de dados por dia.
>> > >
>> > > vixi, isso é MUITA coisa... hehe :)
>> > >
>> > >> Atualmente estou começando a analisar bancos de dados orientados a
>> > coluna
>> > >> http://en.wikipedia.org/wiki/Column-oriented_DBMS (ouvi dizer que um
>> > produto da HP está usando
>> > >> o Sybase IQ que é um banco de dados orientado a coluna) para
>> > armazenamento de grandes volumes
>> > >> de dados). Confesso que Banco de Dados não é muito minha praia....
>> > >>
>> > >> Gostaria de receber opiniões das pessoas da lista a respeito desse
>> > conceito de banco de dados ou
>> > >> de algum outro modelo de armazenamento para grandes volumes de dados.
>> > >>
>> > >> Para não ficar tão distante do mundo Python, esse sistema foi todo
>> > desenvolvido em Python.
>> > >
>> > > Olha, eu tenho tido experiência prática com o CouchDB e com o MongoDB.
>> > > Nada no nível de 60 milhões de registros diários, mas as minhas
>> > > opiniões sobre os dois estão assim:
>> > >
>> > > Sobre o CouchDB, estamos usando num sistema onde há mais de 4000
>> > > instituições cadastradas e cada uma delas entra com suas informações,
>> > > *mas* essas informações são peculiares de cada uma (imagine que uma
>> > > universidade federal do Kansas possua informações que divergem por
>> > > definição de uma escola de artes particular de Nova York, e assim por
>> > > diante. O CouchDB é REST nativo e suporta persistência assíncrona.
>> > >
>> > > Sobre o MongoDB, estamos usando num aplicativo pequeno, desktop, que é
>> > > instalado com instalador e em várias redes locais pequenas (de uma a 5
>> > > máquinas cada). O desempenho do Mongo me pareceu superior, é muito
>> > > fácil de instalar standalone, e às vezes lembra o memcache (ele tem um
>> > > cache em memória na fronteira entre a comunicação e a persistência.
>> > > Por outro lado, não tem REST nem persistência assíncrona (coisas que
>> > > estão em desenvolvimento). Outra coisa peculiar do Mongo é que o BSON
>> > > (formato semelhante ao JSON) é usado para filtro, map/reduce e o
>> > > diabo, e às vezes é meio esquisito, com JavaScript e umas macros no
>> > > meio da história.
>> > >
>> > > Resumindo, o CouchDB parece mais lento, porém mais elegante. O Mongo
>> > > parece mais prático para trabalhar distribuído. E outra coisa: o
>> > > CouchDB é Erlang e o MongoDB é C puro, ou seja...
>> > >
>> > > Bom, é isso o que eu tenho visto até aqui :)
>> > >
>> > > --
>> > > Marinho Brandão (José Mário)
>> > > http://marinhobrandao.com/
>> > >
>> >
>> > --
>> > Marinho Brandão (José Mário)
>> > http://marinhobrandao.com/
>> >
>> >
>>
>> --
>> Ship ahoy! Hast seen the While Whale?
>> - Melville's Captain Ahab
>>
>> [As partes desta mensagem que não continham texto foram removidas]
>>
>>
>
>
> --
> Marinho Brandão (José Mário)
> http://marinhobrandao.com/
>
>
> ------------------------------------
>
> ,-----------------------------------------------------------.
> | Antes de enviar um e-mail para o grupo leia:              |
> | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar  |
> | E se você é usuário do BOL lembre-se de cadastrar o       |
> | e-mail do grupo na lista branca do seu sistema anti-spam. |
> `-----------------------------------------------------------´Links do Yahoo!
Grupos
>
>
>



--
Ship ahoy! Hast seen the While Whale?
   - Melville's Captain Ahab

Divulgando a pedido do Hugo Corbucci do IME/USP e do Dojo@SP:

>> Convidamos à participação da conferência nacional sobre métodos ágeis
>> Agile Brazil. O evento será de 22 a 25 de Junho na PUCRS, em Porto Alegre.
>> Gostaríamos de convidá-los a participar com trabalhos, palestras e
>> workshops. Mais detalhes para a submissão na chamada de trabalhos assim como
>> no sistema de submissões disponível em http://submissoes.agilebrazil.com.
>> Teremos a chamada tradicional para palestras, tutoriais e workshops além
>> do primeiro evento voltado especificamente para a academia (WBMA) com
>> submissão de artigos científicos.
>> Já estão confirmadas as presenças do Martin Fowler (vejam
>> em martinfowler.com/), cientista chefe da ThoughtWorks, Philippe Kruchten,
>> hoje professor da UBC em Vancouver mas que por muitos anos liderou a equipe
>> da Rational Software no desenvolvimento do RUP, David Hussman, vencedor do
>> Gordon Pask Award em 2010 e Klaus Wuestefeld, um dos pioneiros de métodos
>> ágeis no Brasil.
>>
>> Convidamos a todos para que submetam seus trabalhos e participem. As
>> inscrições devem abrir em Março. Interessados em patrocinar podem entrar em
>> contato pelo patrocinios@....
>> Quaisquer outras dúvidas podem ser enviadas no contato@....
>>
>> Obrigado a todos pela atenção,
>> Organizadores e Colaboradores do Agile Brazil


[ ]s
Luciano

--
"""
Many were increasingly of the opinion that they'd all made a big
mistake in coming down from the trees in the first place. And some
said that even the trees had been a bad move, and that no one should
ever have left the oceans. (DA/HHGTTG)
"""

Aqui: http://unxutils.sourceforge.net/

Se for algo simples, acho melhor não utilizar wget, pois criaria mais uma
"dependência". A não ser que seja algum problema crítico relacionado a
performance mesmo.

Porém se for algo mais complexo, não vejo motivos para não utilizá-lo.

Caio Ariede
http://caioariede.com/


2010/2/8 Rafael Sierra <rafaeljsg14@...>

>
>
> 2010/2/8 Henrique Baggio <hnrqbaggio@... <hnrqbaggio%40gmail.com>>:
>
> > 2010/2/8 @maltzsama <causbla@... <causbla%40gmail.com>>
> >
> >>
> >>
> >> Mas fazer a "gambiarra" de usar o wget dentro do python nao dificulta
> >> uma possivel portabilidade de um *NIX para um windows ou ate um
> >> celular, por exemplo? Não se torna mais facil realemnte fazer o que
> >> ele esta fazendo ao nao incorporar o wget(Ferramenta caracteristica do
> >> *nix)?
> >>
>
> Com o cygwin você consegue instalar o wget no windows e usar de boa.
>
> Mas acredito que a melhor solução seria fazer uma especie de
> {{{
> import time
> while True:
> xpto.read(50*102.4) # 50KB
> time.sleep(.1)
> }}}
>
> Assim voce garante que vai ler ate 50KB/s :)
>
>
> >
> > Não sei como resolver no caso de um celular, mas existe uma implementação
> do
> > Wget pro Windows. Não tenho o link à mão, mas uma busca simples no Google
> > encontra com certeza. Eu já testei e funcionou bem (Acho que as suites
> que
> > portam o Unix pro Windows como MinGW devem vir com um wget tb).
> >
> > Eu já trouxe essa dúvida uma vez pra lista e no fim achei que usar um
> wget +
> > subprocess não era não ruim assim pq não precisa reinventar a roda.
> >
> > E quanto aos problemas do Rudson, acho que tem mesmo a ver com o fato de
> se
> > procurar linhas num binário, mas posso estar falando bobogem.
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
> > ------------------------------------
>
> >
> > ,----------------------------------------------------------.
> > | Antes de enviar um e-mail para o grupo leia:              |
> > | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar  |
> > | E se você é usuário do BOL lembre-se de cadastrar o       |
> > | e-mail do grupo na lista branca do seu sistema anti-spam. |
> > `----------------------------------------------------------´Links do
> Yahoo! Grupos
> >
> >
> >
>
> --
> Rafael Sierra
> http://blog.stiod.com
>
>


[As partes desta mensagem que não continham texto foram removidas]

Ok pessoal, mas não se trata de ser uma 'gambiarra' utilizar o wget, e o
aplicativo que estou implementando, até o momento, é apenas um
passatempo pessoal.

Em um outro projeto que trabalho uso o wget e gosto muito do resultado.
Apenas estou avaliando o que é possível se fazer com as libs do Python.

Vou implementar as ideias do Alison e depois posto aqui os resultados.

Valeu...

On 08-02-2010 14:59, Rafael Sierra wrote:
>
> 2010/2/8 Henrique Baggio <hnrqbaggio@...
> <mailto:hnrqbaggio%40gmail.com>>:
> > 2010/2/8 @maltzsama <causbla@... <mailto:causbla%40gmail.com>>
> >
> >>
> >>
> >> Mas fazer a "gambiarra" de usar o wget dentro do python nao dificulta
> >> uma possivel portabilidade de um *NIX para um windows ou ate um
> >> celular, por exemplo? Não se torna mais facil realemnte fazer o que
> >> ele esta fazendo ao nao incorporar o wget(Ferramenta caracteristica do
> >> *nix)?
> >>
>
> Com o cygwin você consegue instalar o wget no windows e usar de boa.
>
> Mas acredito que a melhor solução seria fazer uma especie de
> {{{
> import time
> while True:
> xpto.read(50*102.4) # 50KB
> time.sleep(.1)
> }}}
>
> Assim voce garante que vai ler ate 50KB/s :)
>
> >
> > Não sei como resolver no caso de um celular, mas existe uma
> implementação do
> > Wget pro Windows. Não tenho o link à mão, mas uma busca simples no
> Google
> > encontra com certeza. Eu já testei e funcionou bem (Acho que as
> suites que
> > portam o Unix pro Windows como MinGW devem vir com um wget tb).
> >
> > Eu já trouxe essa dúvida uma vez pra lista e no fim achei que usar
> um wget +
> > subprocess não era não ruim assim pq não precisa reinventar a roda.
> >
> > E quanto aos problemas do Rudson, acho que tem mesmo a ver com o
> fato de se
> > procurar linhas num binário, mas posso estar falando bobogem.
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
> > ------------------------------------
> >
> > ,----------------------------------------------------------.
> > | Antes de enviar um e-mail para o grupo leia:              |
> > | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar
> <http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar>  |
> > | E se você é usuário do BOL lembre-se de cadastrar o       |
> > | e-mail do grupo na lista branca do seu sistema anti-spam. |
> > `----------------------------------------------------------´Links do
> Yahoo! Grupos
> >
> >
> >
>
> --
> Rafael Sierra
> http://blog.stiod.com <http://blog.stiod.com>
>
>



[As partes desta mensagem que não continham texto foram removidas]

2010/2/8 Henrique Baggio <hnrqbaggio@...>:
> 2010/2/8 @maltzsama <causbla@...>
>
>>
>>
>> Mas fazer a "gambiarra" de usar o wget dentro do python nao dificulta
>> uma possivel portabilidade de um *NIX para um windows ou ate um
>> celular, por exemplo? Não se torna mais facil realemnte fazer o que
>> ele esta fazendo ao nao incorporar o wget(Ferramenta caracteristica do
>> *nix)?
>>

Com o cygwin você consegue instalar o wget no windows e usar de boa.

Mas acredito que a melhor solução seria fazer uma especie de
{{{
import time
while True:
     xpto.read(50*102.4) # 50KB
     time.sleep(.1)
}}}

Assim voce garante que vai ler ate 50KB/s :)

>
> Não sei como resolver no caso de um celular, mas existe uma implementação
do
> Wget pro Windows. Não tenho o link à mão, mas uma busca simples no Google
> encontra com certeza. Eu já testei e funcionou bem (Acho que as suites que
> portam o Unix pro Windows como MinGW devem vir com um wget tb).
>
> Eu já trouxe essa dúvida uma vez pra lista e no fim achei que usar um wget +
> subprocess não era não ruim assim pq não precisa reinventar a roda.
>
> E quanto aos problemas do Rudson, acho que tem mesmo a ver com o fato de se
> procurar linhas num binário, mas posso estar falando bobogem.
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>
> ------------------------------------
>
> ,-----------------------------------------------------------.
> | Antes de enviar um e-mail para o grupo leia:              |
> | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar  |
> | E se você é usuário do BOL lembre-se de cadastrar o       |
> | e-mail do grupo na lista branca do seu sistema anti-spam. |
> `-----------------------------------------------------------´Links do Yahoo!
Grupos
>
>
>



--
Rafael Sierra
http://blog.stiod.com

Em 8/2/2010 14:36, @maltzsama escreveu:
>
>
> Mas fazer a "gambiarra" de usar o wget dentro do python nao dificulta
> uma possivel portabilidade de um *NIX para um windows ou ate um
> celular, por exemplo? Não se torna mais facil realemnte fazer o que
> ele esta fazendo ao nao incorporar o wget(Ferramenta caracteristica do
> *nix)?
>
> Saudações
>
> Demetrius Albuquerque
> Linux & SO www.maltzsama.wordpress.com
> do Contra Rock http://www.estacaodorock.com/v2/?p=13&blog_name=docontra
> <http://www.estacaodorock.com/v2/?p=13&blog_name=docontra>
>
> Em 8 de fevereiro de 2010 12:27, Allison Vollmann
> <allisonvoll@... <mailto:allisonvoll%40yahoo.com.br>> escreveu:
>  >
>  > Em 8/2/2010 13:13, Rudson Alves escreveu:
>  > >
>  > >
>  > > Fiz uma rotina para fazer download de arquivos na internet usando o
>  > > urllib, mas estou tendo duas dificuldades as quais não sei ainda como
>  > > resolver.
>  > >
>  > > A rotina está em:
>  > >
>  > > http://paste.ideaslabs.com/show/XDbYw5Fh8k
> <http://paste.ideaslabs.com/show/XDbYw5Fh8k>
>  > > <http://paste.ideaslabs.com/show/XDbYw5Fh8k
> <http://paste.ideaslabs.com/show/XDbYw5Fh8k>>
>  > >
>  > > onde 'human_bytes' e 'human_time' são duas funções para formatar o
>  > > número de bytes em kB, MB, ... e o tempo em hh:mm:ss. Para não perder o
>  > > foco, por hora defina-as como:
>  > >
>  > > def human_bytes(s):
>  > > return '%dB' % s
>  > >
>  > > def human_time(t):
>  > > return '%ds' % t
>  > >
>  > > A rotina funciona muito bem, a menos dos dois problemas que encontrei:
>  > >
>  > > 1 - a taxa de download é 1/4 de um wget (na rede em que me encontro
>  > > agora). Bom não precisava ser uma taxa igual ou superior a do wget, mas
>  > > 1/4 me surpreendeu muito. Enquanto que esta função em python baixava a
>  > > 250kB/s o wget fazia o mesmo a 1M/s, na mesma rede, independente da
>  > > ordem em que fossem executados, antes que alguém pense que é cache.
>  > >
>  > > 2 - em alguns casos o download é cancelado e a função não gera erro
>  > > algum, o 'try' da linha 34-66 não me retorna nada. Por este motivo tive
>  > > que fazer a checagem do tamanho baixado na linha 70.
>  > >
>  > > Quanto ao problema 1, na forma que a função está definida, ela
> baixa uma
>  > > linha de cada vez do arquivo solicitado, que em muitos casos é um
>  > > binário. Imagino que ele deve baixar os bytes em sequência até
> encontrar
>  > > o ascii indicando a mudança de linha. Acho que por isto não
> consegue uma
>  > > taxa de download boa, pois num instante a linha baixada possui 1 byte e
>  > > noutro 205, 14, 65, ... Chequei isto imprimindo o comprimento da linha,
>  > > e de fato, até onde compreendi, ocorre algo assim.
>  > >
>  > > Neste dois requisitos o wget me resolveria o problema muito bem,
> mas não
>  > > gostaria de ter que chamá-lo pelo Python, antes de ter certeza de que o
>  > > mesmo não pode ser feito de forma eficiente apenas com o Pyton....
>  > >
>  > > Alguém tem alguma ideia de como melhorar isto?
>  > >
>  > > __________________________________________________________
>  > > Veja quais são os assuntos do momento no Yahoo! +Buscados
>  > > http://br.maisbuscados.yahoo.com <http://br.maisbuscados.yahoo.com>
> <http://br.maisbuscados.yahoo.com <http://br.maisbuscados.yahoo.com>>
>  > >
>  > > [As partes desta mensagem que não continham texto foram removidas]
>  > >
>  > >
>  >
>  >
>  > Olá,
>  >
>  >
>  > Primeira coisa que notei em seu código, você usou "file" diretamente
>  > para instânciar um objeto deste tipo, de acordo com a documentação
>  > oficial é recomendável utilizar a função built-in "open" ao invés de
>  > invocar "file" diretamente (o resultado é o mesmo, um objeto do tipo
> "file")
>  >
>  > Outra coisa considerando que é um arquivo binário, você pode adicionar
>  > este parâmetro ("b") específico para arquivos binários ao abrir o
>  > arquivo, (ex: "wb", "rb")
>  >
>  > E como você mesmo disse, mas insiste em utilizar o generator para ler as
>  > linhas, em um arquivo binário não existem quebras de linha (provável que
>  > ele encontre um valor que seja interpretado como o mesmo, mas não será
>  > tão freqüênte), ao invés disso você deve usar o "read" que é um
wrapper
>  > da função de mesmo nome de baixo nível da biblioteca de sockets do
>  > sistema, nesse método você deve passar como parâmetro o numero de bytes
>  > a serem lidos, então o seu mainloop ficaria mais ou menos assim:
>  >
>  > >>> while True:
>  > ....    buffer = wget.read(512)
>  > ....
>  > ....    if not buffer:
>  > ....        break
>  > ....
>  > ....    fout.write(buffer)
>  >
>  > Onde o parâmetro de "read" é o numero de bytes a serem lidos por
>  > iteração, você pode instânciar isso em uma variável global ou atributo
>  > para facilitar alterações.
>  >
>  > Só lembrando, chamar o wget pelo Python não é nenhuma gambiarra, visto
>  > que esta é uma das filosofias Unix ("Faça programas que se comuniquem
>  > com outros programas"), basta utilizar módulos como o "subproccess" e
>  > fazer o parsing do Output do wget se quiser ler o progresso do download
>  > ou outras informações, é só consultar as manpages do wget e verá que
tem
>  > várias opções de formatar este output, assim facilita o serviço de
fazer
>  > o parsing dos dados, inclusive existem vários gerenciadores de download
>  > que utilizam o wget como backend. E terá a vantagem de não ter que
>  > re-implementar a continuação de downloads.
>  >
>  > A[]'s
>  >
>  >
>  >
>  >
>  >
>  > ------------------------------------
>  >
>  > ,----------------------------------------------------------.
>  > | Antes de enviar um e-mail para o grupo leia:              |
>  > | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar
> <http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar>  |
>  > | E se você é usuário do BOL lembre-se de cadastrar o       |
>  > | e-mail do grupo na lista branca do seu sistema anti-spam. |
>  > `----------------------------------------------------------´Links do
> Yahoo! Grupos
>  >
>  >
>
>


Isso é relativo, pois utilizando o wget ele tem a vantagem de não ter
que re-implementar todas as funcionalidades do mesmo (se for
necessário), e se o alvo dele for ser multiplataforma ai a história é
outra, mas considerando que existe wget para Windows, e alguns senão boa
parte dos celulares que rodam Python possuem OS baseado em *nix, ai ele
teria mais uma dependência para sua aplicação.

Mas como eu disse, depende do caso de uso e da preferência de cada um,
pode ser viável.

Foi apenas mais uma solução, e não a única.

Três vivas ao Top-Posting!

A[]'s

2010/2/8 @maltzsama <causbla@...>

>
>
> Mas fazer a "gambiarra" de usar o wget dentro do python nao dificulta
> uma possivel portabilidade de um *NIX para um windows ou ate um
> celular, por exemplo? Não se torna mais facil realemnte fazer o que
> ele esta fazendo ao nao incorporar o wget(Ferramenta caracteristica do
> *nix)?
>

Não sei como resolver no caso de um celular, mas existe uma implementação do
Wget pro Windows. Não tenho o link à mão, mas uma busca simples no Google
encontra com certeza. Eu já testei e funcionou bem (Acho que as suites que
portam o Unix pro Windows como MinGW devem vir com um wget tb).

Eu já trouxe essa dúvida uma vez pra lista e no fim achei que usar um wget +
subprocess não era não ruim assim pq não precisa reinventar a roda.

E quanto aos problemas do Rudson, acho que tem mesmo a ver com o fato de se
procurar linhas num binário, mas posso estar falando bobogem.


[As partes desta mensagem que não continham texto foram removidas]

Mas fazer a "gambiarra" de usar o wget dentro do python nao dificulta
uma possivel portabilidade de um *NIX para um windows ou ate um
celular, por exemplo? Não se torna mais facil realemnte fazer o que
ele esta fazendo ao nao incorporar o wget(Ferramenta caracteristica do
*nix)?

Saudações

Demetrius Albuquerque
Linux & SO www.maltzsama.wordpress.com
do Contra Rock http://www.estacaodorock.com/v2/?p=13&blog_name=docontra


Em 8 de fevereiro de 2010 12:27, Allison Vollmann
<allisonvoll@...> escreveu:
>
> Em 8/2/2010 13:13, Rudson Alves escreveu:
> >
> >
> > Fiz uma rotina para fazer download de arquivos na internet usando o
> > urllib, mas estou tendo duas dificuldades as quais não sei ainda como
> > resolver.
> >
> > A rotina está em:
> >
> > http://paste.ideaslabs.com/show/XDbYw5Fh8k
> > <http://paste.ideaslabs.com/show/XDbYw5Fh8k>
> >
> > onde 'human_bytes' e 'human_time' são duas funções para formatar o
> > número de bytes em kB, MB, ... e o tempo em hh:mm:ss. Para não perder o
> > foco, por hora defina-as como:
> >
> > def human_bytes(s):
> > return '%dB' % s
> >
> > def human_time(t):
> > return '%ds' % t
> >
> > A rotina funciona muito bem, a menos dos dois problemas que encontrei:
> >
> > 1 - a taxa de download é 1/4 de um wget (na rede em que me encontro
> > agora). Bom não precisava ser uma taxa igual ou superior a do wget, mas
> > 1/4 me surpreendeu muito. Enquanto que esta função em python baixava a
> > 250kB/s o wget fazia o mesmo a 1M/s, na mesma rede, independente da
> > ordem em que fossem executados, antes que alguém pense que é cache.
> >
> > 2 - em alguns casos o download é cancelado e a função não gera erro
> > algum, o 'try' da linha 34-66 não me retorna nada. Por este motivo tive
> > que fazer a checagem do tamanho baixado na linha 70.
> >
> > Quanto ao problema 1, na forma que a função está definida, ela baixa uma
> > linha de cada vez do arquivo solicitado, que em muitos casos é um
> > binário. Imagino que ele deve baixar os bytes em sequência até encontrar
> > o ascii indicando a mudança de linha. Acho que por isto não consegue uma
> > taxa de download boa, pois num instante a linha baixada possui 1 byte e
> > noutro 205, 14, 65, ... Chequei isto imprimindo o comprimento da linha,
> > e de fato, até onde compreendi, ocorre algo assim.
> >
> > Neste dois requisitos o wget me resolveria o problema muito bem, mas não
> > gostaria de ter que chamá-lo pelo Python, antes de ter certeza de que o
> > mesmo não pode ser feito de forma eficiente apenas com o Pyton....
> >
> > Alguém tem alguma ideia de como melhorar isto?
> >
> > __________________________________________________________
> > Veja quais são os assuntos do momento no Yahoo! +Buscados
> > http://br.maisbuscados.yahoo.com <http://br.maisbuscados.yahoo.com>
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
>
>
> Olá,
>
>
> Primeira coisa que notei em seu código, você usou "file" diretamente
> para instânciar um objeto deste tipo, de acordo com a documentação
> oficial é recomendável utilizar a função built-in "open" ao invés de
> invocar "file" diretamente (o resultado é o mesmo, um objeto do tipo "file")
>
> Outra coisa considerando que é um arquivo binário, você pode adicionar
> este parâmetro ("b") específico para arquivos binários ao abrir o
> arquivo, (ex: "wb", "rb")
>
> E como você mesmo disse, mas insiste em utilizar o generator para ler as
> linhas, em um arquivo binário não existem quebras de linha (provável que
> ele encontre um valor que seja interpretado como o mesmo, mas não será
> tão freqüênte), ao invés disso você deve usar o "read" que é um wrapper
> da função de mesmo nome de baixo nível da biblioteca de sockets do
> sistema, nesse método você deve passar como parâmetro o numero de bytes
> a serem lidos, então o seu mainloop ficaria mais ou menos assim:
>
>  >>> while True:
> ....    buffer = wget.read(512)
> ....
> ....    if not buffer:
> ....        break
> ....
> ....    fout.write(buffer)
>
> Onde o parâmetro de "read" é o numero de bytes a serem lidos por
> iteração, você pode instânciar isso em uma variável global ou atributo
> para facilitar alterações.
>
> Só lembrando, chamar o wget pelo Python não é nenhuma gambiarra, visto
> que esta é uma das filosofias Unix ("Faça programas que se comuniquem
> com outros programas"), basta utilizar módulos como o "subproccess" e
> fazer o parsing do Output do wget se quiser ler o progresso do download
> ou outras informações, é só consultar as manpages do wget e verá que tem
> várias opções de formatar este output, assim facilita o serviço de fazer
> o parsing dos dados, inclusive existem vários gerenciadores de download
> que utilizam o wget como backend. E terá a vantagem de não ter que
> re-implementar a continuação de downloads.
>
> A[]'s
>
>
>
>
>
> ------------------------------------
>
> ,-----------------------------------------------------------.
> | Antes de enviar um e-mail para o grupo leia:              |
> | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar  |
> | E se você é usuário do BOL lembre-se de cadastrar o       |
> | e-mail do grupo na lista branca do seu sistema anti-spam. |
> `-----------------------------------------------------------´Links do Yahoo!
Grupos
>
>

Em 8/2/2010 13:13, Rudson Alves escreveu:
>
>
> Fiz uma rotina para fazer download de arquivos na internet usando o
> urllib, mas estou tendo duas dificuldades as quais não sei ainda como
> resolver.
>
> A rotina está em:
>
> http://paste.ideaslabs.com/show/XDbYw5Fh8k
> <http://paste.ideaslabs.com/show/XDbYw5Fh8k>
>
> onde 'human_bytes' e 'human_time' são duas funções para formatar o
> número de bytes em kB, MB, ... e o tempo em hh:mm:ss. Para não perder o
> foco, por hora defina-as como:
>
> def human_bytes(s):
> return '%dB' % s
>
> def human_time(t):
> return '%ds' % t
>
> A rotina funciona muito bem, a menos dos dois problemas que encontrei:
>
> 1 - a taxa de download é 1/4 de um wget (na rede em que me encontro
> agora). Bom não precisava ser uma taxa igual ou superior a do wget, mas
> 1/4 me surpreendeu muito. Enquanto que esta função em python baixava a
> 250kB/s o wget fazia o mesmo a 1M/s, na mesma rede, independente da
> ordem em que fossem executados, antes que alguém pense que é cache.
>
> 2 - em alguns casos o download é cancelado e a função não gera erro
> algum, o 'try' da linha 34-66 não me retorna nada. Por este motivo tive
> que fazer a checagem do tamanho baixado na linha 70.
>
> Quanto ao problema 1, na forma que a função está definida, ela baixa uma
> linha de cada vez do arquivo solicitado, que em muitos casos é um
> binário. Imagino que ele deve baixar os bytes em sequência até encontrar
> o ascii indicando a mudança de linha. Acho que por isto não consegue uma
> taxa de download boa, pois num instante a linha baixada possui 1 byte e
> noutro 205, 14, 65, ... Chequei isto imprimindo o comprimento da linha,
> e de fato, até onde compreendi, ocorre algo assim.
>
> Neste dois requisitos o wget me resolveria o problema muito bem, mas não
> gostaria de ter que chamá-lo pelo Python, antes de ter certeza de que o
> mesmo não pode ser feito de forma eficiente apenas com o Pyton....
>
> Alguém tem alguma ideia de como melhorar isto?
>
> __________________________________________________________
> Veja quais são os assuntos do momento no Yahoo! +Buscados
> http://br.maisbuscados.yahoo.com <http://br.maisbuscados.yahoo.com>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>


Olá,


Primeira coisa que notei em seu código, você usou "file" diretamente
para instânciar um objeto deste tipo, de acordo com a documentação
oficial é recomendável utilizar a função built-in "open" ao invés de
invocar "file" diretamente (o resultado é o mesmo, um objeto do tipo "file")

Outra coisa considerando que é um arquivo binário, você pode adicionar
este parâmetro ("b") específico para arquivos binários ao abrir o
arquivo, (ex: "wb", "rb")

E como você mesmo disse, mas insiste em utilizar o generator para ler as
linhas, em um arquivo binário não existem quebras de linha (provável que
ele encontre um valor que seja interpretado como o mesmo, mas não será
tão freqüênte), ao invés disso você deve usar o "read" que é um wrapper
da função de mesmo nome de baixo nível da biblioteca de sockets do
sistema, nesse método você deve passar como parâmetro o numero de bytes
a serem lidos, então o seu mainloop ficaria mais ou menos assim:

  >>> while True:
....    buffer = wget.read(512)
....
....    if not buffer:
....        break
....
....    fout.write(buffer)

Onde o parâmetro de "read" é o numero de bytes a serem lidos por
iteração, você pode instânciar isso em uma variável global ou atributo
para facilitar alterações.

Só lembrando, chamar o wget pelo Python não é nenhuma gambiarra, visto
que esta é uma das filosofias Unix ("Faça programas que se comuniquem
com outros programas"), basta utilizar módulos como o "subproccess" e
fazer o parsing do Output do wget se quiser ler o progresso do download
ou outras informações, é só consultar as manpages do wget e verá que tem
várias opções de formatar este output, assim facilita o serviço de fazer
o parsing dos dados, inclusive existem vários gerenciadores de download
que utilizam o wget como backend. E terá a vantagem de não ter que
re-implementar a continuação de downloads.

A[]'s

Alexandre,

se for seguir o seu raciocínio, então para quê existem ORMs?

1) Cada banco relacional possui sua variante do SQL e do padrão de DDL/DML etc,
2) Cada um deles possui uma forma de comunicação diferente
3) Cada um deles possui uma forma de indexar e armazenar páginas próprias
4) Já existem bibliotecas com o psycopg, MySQLdb, etc para implementar
as particularidades e comunicação de cada um

Ou seja, porque não usar direto o psycopg? Pra que existem interfaces
como ODBC, JDBC, etc.?

Veja, a gente precisa se lembrar de que relacional ou não relacional,
todos eles são REPOSITÓRIOS DE DADOS, e os dados que são direcionados
a eles geralmente vêm de uma classe de modelo. Ponto final.

Ou seja: todos eles são formas diferentes de se armazenar dados que
estavam em objetos... ou seja:

MAPEAMENTO OBJETO -> REPOSITORIO.

Agora, sobre qual é o tipo do repositório, isso é questão pro adapter
(ou backend, como preferir) resolver, e ele provavelmente vai usar as
bibliotecas já existentes (psycopg, pymongodb, MySQLdb, etc) pra isso.

Quanto aos backends de bancos NoSQL para Django, dê uma olhada no fonte deles ;)

Em 6 de fevereiro de 2010 23:07, Alexandre Fiori <fiorix@...> escreveu:
>
>
>
> o que posso compartilhar aqui é o seguinte:
>
> alguns amigos que trabalham na boo-box.com, com o sistema em ruby, usaram
> couchdb e tiveram péssimas experiências. muito problema com desempenho e
> estabilidade - como vários crashes por dia em high-load.
>
> sobre bibliotecas de persistência, acho bem improvável que passem a suportar
> "nosql" pois esses bancos não seguem uma linguagem comum como sql, que já
> não se enquadra no PEP 249 (python database api specification v2.0:
> http://www.python.org/dev/peps/pep-0249/)
>
> voltando ao assunto original desta thread, the é desempenho vs capacidade,
> posso compartilhar o seguinte:
>
> o maior sistema que já desenvolvi com python e rdbm era baseado em pgsql;
> mas antes, fiz diversos testes com mysql, sybase, firebird e até lucene -
> pois um dos requisitos era full-text search. o pgsql foi o que se comportou
> melhor, com cerca de 10 milhões de registros adicionados e removidos por
> dia, mantendo uma média de 250 milhões de registros constantes na base.
>
> usando sharding, dividindo read e write para máquinas diferentes, com 6
> máquinas (3 masters e 3 slaves), funcionou perfeito. a indexação é meio
> lenta, pois cada insert já indexava também os campos de busca por texto,
> usando "fast full-text search" - artigo do meu blog:
> http://fiorix.wordpress.com/2009/03/12/postgresql-fast-full-text-search/
>
> por fim, sobre nosql:
>
> tenho mantido dois "drivers" para bancos completamente diferentes, baseados
> em twisted, para redis e mongodb.
> http://github.com/fiorix/txredisapi
> http://github.com/fiorix/mongo-async-python-driver
>
> é impossível que essas APIs sejam padronizadas e enquadradas em algo como
> sqlalchemy, pois os métodos providos por esses bancos são totalmente fora do
> padrão sql.
>
> ainda, vale lembrar que o mongodb (que é c++ e não c) permite acessar os
> registros através do filesystem, usando o gridfs:
>
> http://www.mongodb.org/display/DOCS/GridFS+Specification
> e um módulo REST pro nginx, que acessa o gridfs:
> http://github.com/mdirolf/nginx-gridfs
>
> a única limitação é que cada registro pode ter no máximo 4MB. além disso, o
> mongodb tem uma limitação de base máxima de 2.5GB em máquinas 32bit - já em
> máquinas 64bit o tamanho da base é ilimitada, e em ambos os casos ele é
> super rápido pois o acesso aos dados é feito por meio de mmap, onde o kernel
> já se encarrega de fazer cache dos dados mais acessados.
>
> http://blog.mongodb.org/post/137788967/32-bit-limitations
>
> espero que ajude.
>
> abs
>
> AF
>
> 2010/2/6 Marinho Brandao <marinho@...>
>
> >
> >
> > Ha, e mais uma coisa...
> >
> > Uma coisa que andei falando recentemente na lista do Tornado e no
> > Twitter, mas falei também há uns 4 ou 5 anos quando entrei na
> > python-brasil:
> >
> > Eu sinto falta de uma biblioteca de persistência no Python *que não
> > seja presa* ao modelo ORM. De fato, as bibliotecas que eu conheço
> > razoavelmente (SQLAlchemy, Django e SQLObject) estão *muito* presas ao
> > relacional e à normalização. Chega a ser inviável adaptá-los a bancos
> > NoSQL.
> >
> > Eu já fiz uma OPF (que acho um nome mais razoável do que ORM) em
> > Delphi que era bem mais compatível com esse modelo, e se não fosse a
> > inviabilidade de reinventar a roda, eu faria uma semelhante no Python,
> > mas o fato é que hoje não é nada prático usar mais de um banco de
> > dados (de paradigmas diferentes) nas bibliotecas que eu conheço no
> > Python
> >
> > Só uma centavo a mais... :)
> >
> > Em 6 de fevereiro de 2010 19:13, Marinho Brandao
<marinho@...<marinho%40gmail.com>>
> > escreveu:
> >
> > > Oi Marco, boa noite
> > >
> > >> Aproveitando a mensagem do Luciano e essa discussão off-topic sobre
> > Banco de Dados...
> > >
> > > nem tão off assim :P
> > >
> > >> Gostaria da receber opinião do pessoal da lista para o seguinte
> > problema.
> > >>
> > >> Já faz algum tempo que participo do desenvolvimento de um sistema que
> > não usa Banco de Dados,
> > >> todas as informações são armazenadas em arquivos proprietários no "file
> > system". O motivo
> > >> de usar essa abordagem é porque ainda não encontramos uma solução viável
> > de banco de dados
> > >> para armazenar um grande volume de dados. Estou falando algo em torno de
> > 60 milhöes de
> > >> registros sendo inseridos na base de dados por dia.
> > >
> > > vixi, isso é MUITA coisa... hehe :)
> > >
> > >> Atualmente estou começando a analisar bancos de dados orientados a
> > coluna
> > >> http://en.wikipedia.org/wiki/Column-oriented_DBMS (ouvi dizer que um
> > produto da HP está usando
> > >> o Sybase IQ que é um banco de dados orientado a coluna) para
> > armazenamento de grandes volumes
> > >> de dados). Confesso que Banco de Dados não é muito minha praia....
> > >>
> > >> Gostaria de receber opiniões das pessoas da lista a respeito desse
> > conceito de banco de dados ou
> > >> de algum outro modelo de armazenamento para grandes volumes de dados.
> > >>
> > >> Para não ficar tão distante do mundo Python, esse sistema foi todo
> > desenvolvido em Python.
> > >
> > > Olha, eu tenho tido experiência prática com o CouchDB e com o MongoDB.
> > > Nada no nível de 60 milhões de registros diários, mas as minhas
> > > opiniões sobre os dois estão assim:
> > >
> > > Sobre o CouchDB, estamos usando num sistema onde há mais de 4000
> > > instituições cadastradas e cada uma delas entra com suas informações,
> > > *mas* essas informações são peculiares de cada uma (imagine que uma
> > > universidade federal do Kansas possua informações que divergem por
> > > definição de uma escola de artes particular de Nova York, e assim por
> > > diante. O CouchDB é REST nativo e suporta persistência assíncrona.
> > >
> > > Sobre o MongoDB, estamos usando num aplicativo pequeno, desktop, que é
> > > instalado com instalador e em várias redes locais pequenas (de uma a 5
> > > máquinas cada). O desempenho do Mongo me pareceu superior, é muito
> > > fácil de instalar standalone, e às vezes lembra o memcache (ele tem um
> > > cache em memória na fronteira entre a comunicação e a persistência.
> > > Por outro lado, não tem REST nem persistência assíncrona (coisas que
> > > estão em desenvolvimento). Outra coisa peculiar do Mongo é que o BSON
> > > (formato semelhante ao JSON) é usado para filtro, map/reduce e o
> > > diabo, e às vezes é meio esquisito, com JavaScript e umas macros no
> > > meio da história.
> > >
> > > Resumindo, o CouchDB parece mais lento, porém mais elegante. O Mongo
> > > parece mais prático para trabalhar distribuído. E outra coisa: o
> > > CouchDB é Erlang e o MongoDB é C puro, ou seja...
> > >
> > > Bom, é isso o que eu tenho visto até aqui :)
> > >
> > > --
> > > Marinho Brandão (José Mário)
> > > http://marinhobrandao.com/
> > >
> >
> > --
> > Marinho Brandão (José Mário)
> > http://marinhobrandao.com/
> >
> >
>
> --
> Ship ahoy! Hast seen the While Whale?
> - Melville's Captain Ahab
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>


--
Marinho Brandão (José Mário)
http://marinhobrandao.com/

Fiz uma rotina para fazer download de arquivos na internet usando o urllib, mas
estou tendo duas dificuldades as quais não sei ainda como resolver.

A rotina está em:

http://paste.ideaslabs.com/show/XDbYw5Fh8k

onde 'human_bytes' e 'human_time' são duas funções para formatar o número de
bytes em kB, MB, ... e o tempo em hh:mm:ss. Para não perder o foco, por hora
defina-as como:

def human_bytes(s):
   return '%dB' % s

def human_time(t):
   return '%ds' % t

A rotina funciona muito bem, a menos dos dois problemas que encontrei:

  1 - a taxa de download é 1/4 de um wget (na rede em que me encontro agora). Bom
não precisava ser uma taxa igual ou superior a do wget, mas 1/4 me surpreendeu
muito. Enquanto que esta função em python baixava a 250kB/s o wget fazia o mesmo
a 1M/s, na mesma rede, independente da ordem em que fossem executados, antes que
alguém pense que é cache.

  2 - em alguns casos o download é cancelado e a função não gera erro algum, o
'try' da linha 34-66 não me retorna nada. Por este motivo tive que fazer a
checagem do tamanho baixado na linha 70.

Quanto ao problema 1, na forma que a função está definida, ela baixa uma linha
de cada vez do arquivo solicitado, que em muitos casos é um binário. Imagino que
ele deve baixar os bytes em sequência até encontrar o ascii indicando a mudança
de linha. Acho que por isto não consegue uma taxa de download boa, pois num
instante a linha baixada possui 1 byte e noutro 205, 14, 65, ... Chequei isto
imprimindo o comprimento da linha, e de fato, até onde compreendi, ocorre algo
assim.

Neste dois requisitos o wget me resolveria o problema muito bem, mas não
gostaria de ter que chamá-lo pelo Python, antes de ter certeza de que o mesmo
não pode ser feito de forma eficiente apenas com o Pyton....

Alguém tem alguma ideia de como melhorar isto?


      
________________________________________________________________________________\
____
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

[As partes desta mensagem que não continham texto foram removidas]

o que posso compartilhar aqui é o seguinte:

alguns amigos que trabalham na boo-box.com, com o sistema em ruby, usaram
couchdb e tiveram péssimas experiências. muito problema com desempenho e
estabilidade - como vários crashes por dia em high-load.

sobre bibliotecas de persistência, acho bem improvável que passem a suportar
"nosql" pois esses bancos não seguem uma linguagem comum como sql, que já
não se enquadra no PEP 249 (python database api specification v2.0:
http://www.python.org/dev/peps/pep-0249/)

voltando ao assunto original desta thread, the é desempenho vs capacidade,
posso compartilhar o seguinte:

o maior sistema que já desenvolvi com python e rdbm era baseado em pgsql;
mas antes, fiz diversos testes com mysql, sybase, firebird e até lucene -
pois um dos requisitos era full-text search. o pgsql foi o que se comportou
melhor, com cerca de 10 milhões de registros adicionados e removidos por
dia, mantendo uma média de 250 milhões de registros constantes na base.

usando sharding, dividindo read e write para máquinas diferentes, com 6
máquinas (3 masters e 3 slaves), funcionou perfeito. a indexação é meio
lenta, pois cada insert já indexava também os campos de busca por texto,
usando "fast full-text search" - artigo do meu blog:
http://fiorix.wordpress.com/2009/03/12/postgresql-fast-full-text-search/

por fim, sobre nosql:

tenho mantido dois "drivers" para bancos completamente diferentes, baseados
em twisted, para redis e mongodb.
http://github.com/fiorix/txredisapi
http://github.com/fiorix/mongo-async-python-driver

é impossível que essas APIs sejam padronizadas e enquadradas em algo como
sqlalchemy, pois os métodos providos por esses bancos são totalmente fora do
padrão sql.

ainda, vale lembrar que o mongodb (que é c++ e não c) permite acessar os
registros através do filesystem, usando o gridfs:

http://www.mongodb.org/display/DOCS/GridFS+Specification
e um módulo REST pro nginx, que acessa o gridfs:
http://github.com/mdirolf/nginx-gridfs

a única limitação é que cada registro pode ter no máximo 4MB. além disso,
o
mongodb tem uma limitação de base máxima de 2.5GB em máquinas 32bit - já em
máquinas 64bit o tamanho da base é ilimitada, e em ambos os casos ele é
super rápido pois o acesso aos dados é feito por meio de mmap, onde o kernel
já se encarrega de fazer cache dos dados mais acessados.

http://blog.mongodb.org/post/137788967/32-bit-limitations


espero que ajude.



abs


AF

2010/2/6 Marinho Brandao <marinho@...>

>
>
> Ha, e mais uma coisa...
>
> Uma coisa que andei falando recentemente na lista do Tornado e no
> Twitter, mas falei também há uns 4 ou 5 anos quando entrei na
> python-brasil:
>
> Eu sinto falta de uma biblioteca de persistência no Python *que não
> seja presa* ao modelo ORM. De fato, as bibliotecas que eu conheço
> razoavelmente (SQLAlchemy, Django e SQLObject) estão *muito* presas ao
> relacional e à normalização. Chega a ser inviável adaptá-los a bancos
> NoSQL.
>
> Eu já fiz uma OPF (que acho um nome mais razoável do que ORM) em
> Delphi que era bem mais compatível com esse modelo, e se não fosse a
> inviabilidade de reinventar a roda, eu faria uma semelhante no Python,
> mas o fato é que hoje não é nada prático usar mais de um banco de
> dados (de paradigmas diferentes) nas bibliotecas que eu conheço no
> Python
>
> Só uma centavo a mais... :)
>
> Em 6 de fevereiro de 2010 19:13, Marinho Brandao
<marinho@...<marinho%40gmail.com>>
> escreveu:
>
> > Oi Marco, boa noite
> >
> >> Aproveitando a mensagem do Luciano e essa discussão off-topic sobre
> Banco de Dados...
> >
> > nem tão off assim :P
> >
> >> Gostaria da receber opinião do pessoal da lista para o seguinte
> problema.
> >>
> >> Já faz algum tempo que participo do desenvolvimento de um sistema que
> não usa Banco de Dados,
> >> todas as informações são armazenadas em arquivos proprietários no "file
> system". O motivo
> >> de usar essa abordagem é porque ainda não encontramos uma solução
viável
> de banco de dados
> >> para armazenar um grande volume de dados. Estou falando algo em torno de
> 60 milhöes de
> >> registros sendo inseridos na base de dados por dia.
> >
> > vixi, isso é MUITA coisa... hehe :)
> >
> >> Atualmente estou começando a analisar bancos de dados orientados a
> coluna
> >> http://en.wikipedia.org/wiki/Column-oriented_DBMS (ouvi dizer que um
> produto da HP está usando
> >> o Sybase IQ que é um banco de dados orientado a coluna) para
> armazenamento de grandes volumes
> >> de dados). Confesso que Banco de Dados não é muito minha praia....
> >>
> >> Gostaria de receber opiniões das pessoas da lista a respeito desse
> conceito de banco de dados ou
> >> de algum outro modelo de armazenamento para grandes volumes de dados.
> >>
> >> Para não ficar tão distante do mundo Python, esse sistema foi todo
> desenvolvido em Python.
> >
> > Olha, eu tenho tido experiência prática com o CouchDB e com o MongoDB.
> > Nada no nível de 60 milhões de registros diários, mas as minhas
> > opiniões sobre os dois estão assim:
> >
> > Sobre o CouchDB, estamos usando num sistema onde há mais de 4000
> > instituições cadastradas e cada uma delas entra com suas informações,
> > *mas* essas informações são peculiares de cada uma (imagine que uma
> > universidade federal do Kansas possua informações que divergem por
> > definição de uma escola de artes particular de Nova York, e assim por
> > diante. O CouchDB é REST nativo e suporta persistência assíncrona.
> >
> > Sobre o MongoDB, estamos usando num aplicativo pequeno, desktop, que é
> > instalado com instalador e em várias redes locais pequenas (de uma a 5
> > máquinas cada). O desempenho do Mongo me pareceu superior, é muito
> > fácil de instalar standalone, e às vezes lembra o memcache (ele tem um
> > cache em memória na fronteira entre a comunicação e a persistência.
> > Por outro lado, não tem REST nem persistência assíncrona (coisas que
> > estão em desenvolvimento). Outra coisa peculiar do Mongo é que o BSON
> > (formato semelhante ao JSON) é usado para filtro, map/reduce e o
> > diabo, e às vezes é meio esquisito, com JavaScript e umas macros no
> > meio da história.
> >
> > Resumindo, o CouchDB parece mais lento, porém mais elegante. O Mongo
> > parece mais prático para trabalhar distribuído. E outra coisa: o
> > CouchDB é Erlang e o MongoDB é C puro, ou seja...
> >
> > Bom, é isso o que eu tenho visto até aqui :)
> >
> > --
> > Marinho Brandão (José Mário)
> > http://marinhobrandao.com/
> >
>
> --
> Marinho Brandão (José Mário)
> http://marinhobrandao.com/
>
>



--
Ship ahoy! Hast seen the While Whale?
  - Melville's Captain Ahab


[As partes desta mensagem que não continham texto foram removidas]

me parece que não faz algum sentido tentar padronizar a api dos bancos
nosql, muito menos ter um orm genérico que suporte alguns deles.

pelo seguinte:

1. as características desses bancos não seguem um padrão comum, como os
rdbms
2. esses bancos não possuem uma "linguagem" comum, são sempre APIs que visam
facilitar a programação e eliminar a normalização dos dados
3. os ORMs só existem no python devido ao fato de que o suporte aos rdbms
seguem um padrão, como já mencionei, pep-249
4. o protocolo de comunicação com os bancos nosql varia muito; couch e riak
são rest, mongo e redis são raw socket, com wire protocols completamente
diferentes
5. geração e manutenção de indices é completamente diferente, quando existe
6. linguagem de query e recursos para query completamente diferentes, quando
existe
7. alguns desses bancos possuem recursos como sharding através de
subsistemas (no mongo, através do "mongos"), enquanto outros provêem o mesmo
recurso através da biblioteca de acesso, como é o caso do redis; ainda, pelo
fato do redis ser k/v, o sharding pode ser baseado em consistent hashing em
k, enquanto que no mongo é completamente diferente

por fim, me parece que a idéia de tentar "normalizar" uma api para
acessá-los iria apenas burocratizar o processo de programação, e quando
trocado o backend, tudo iria por água abaixo.

vale lembrar que já existem suportes interessantes do mongo pro django:

http://github.com/vpulim/mango
http://bitbucket.org/kpot/django-mongodb/


abs


AF


2010/2/7 Carlos Ribeiro <carribeiro@...>

>
>
> 2010/2/7 Marinho Brandao <marinho@... <marinho%40gmail.com>>
>
>
> > Opa,
> >
> > > Marinho, posso estar enganado, mas a API em grande parte serve para ...
> > > expor funções relacionais para uso dentro da aplicação. Boa parte do
> > código
> > > serve para transformar acessos a properties em queries, fazer cache,
> etc.
> > > Uma API NoSQL teria que ser diferente. Não faz sentido querer
> implementar
> > a
> > > mesma API, pois senão, além de refazer o código da API em si, ainda
> > teríamos
> > > que escrever funcionalidades que hoje são providas pelo banco. Certo?
> Ou
> > > estou enganado (se estiver pode falar!!!) ?
> >
> > Bom, na maioria dos casos você tem funcionalidades semelhantes (obter
> > objeto, obter lista filtrada por determinados atributos, criar,
> > alterar, excluir, etc.) que diferem na sintaxe ou na forma, mas que
> > possuem o mesmo papel na persistência.
> >
>
> Ou seja: trata-se de mapear as operações sobre o objeto em operações no
> banco, que são expostas como SELCTs, UPDATEs, etc. Se o banco NoSQL em
> questão usar uma interface similar a SQL (como é o caso de alguns bancos)
> então a adaptação é fácil. Outros bancos (como o Couch) usam outro tipo
de
> interface e talvez o mapeamento não seja direto.
>
> No fundo, o que eu estou dizendo é que a API dos ORMs foi feita a partir de
> um conceito relacional; uma camada de persistência sobre um banco NoSQL
> talvez pudesse ser desenhada de outra forma, oferecendo outras primitivas.
>
>
> Quanto a transações e cache, pode variar de acordo com o banco, mas
> > muitas vezes tem também recursos equivalentes e semelhantes.
> >
> > O que diferente mais é na normalização (ForeignKey por exemplo) e no
> > modelo (geralmente em bancos NoSQL não existe modelo). Mas ainda
> > assim, do ponto de vista de negócio, você tem um modelo mínimo
> > implementado na maioria das classes persistentes.
> >
>
> Esse é outro ponto interessante, porque a idéia de usar um ORM,
> especialmente dentro de frameworks como Django, passa pelo conceito de
> Modelo. É a questão do MVC - o ORM suporta o modelo. Uma camada de
> persistência NoSQL teria que ser baseada em modelos, não devido à
> infra-estrutura subjacente do banco, mas porque a aplicação final é
> estruturada sobre os modelos. Talvez isso indique que o próprio MVC tenha
> que ser adaptado ou extendido para usar melhor os conceitos de bancos mais
> flexíveis. Um exemplo é o suporte a herança e mixins, que poderia ser feito
> com mecanismos diferentes dos usados em mapeadores relacionais (através de
> relações n:n, tabelas intermediárias, e coisas do tipo).
>
>
> > Creio que fora alguns detalhes, a diferença maior seria em permitir
> > campos fora do modelo e no uso das bibliotecas de abstração de cada
> > DBMS. Justamente pra quê? Pra você instanciar um objeto, alterar e
> > salvar, e não mudar nada na sintaxe entre um DBMS e outro (aliás, se é
> > um ORM, é porque mapeia do objeto para relacional... mas no caso de
> > banco orientado a JSON ele mapearia objeto para documento, etc... mas
> > veja que sempre é "Objeto" para alguma outra coisa, ou seja: no
> > domínio do objeto, a API deveria ser a mesma, independente da forma de
> > persistência.
> >
>
> Acho complicado fazer algo 100% genérico. Veja bem: todos os bancos
> relacionais oferecem uma API parecida, e mesmo assim, as diferenças que
> ainda existem criam grandes dificuldades para os autores dos ORMs. Eu
> participei por algum tempo do desenvolvimento do SQLObject (há vários anos
> atrás), e me lembro do tipo de dor de cabeça que cada detalhe causa. Se
> você
> se limita a implementar o que é comum entre todas as alternativas, o
> resultado é limitado.
>
> O cenário de bancos NoSQL é muito amplo e representa paradigmas diferentes
> entre si. Não acho que seja possível implementar uma única API que
> aproveite
> bem os recursos de cada. O resultado teria que suportar TODAS as
> funcionalidades, e exigiria re-implementar no nível da camada de
> persistência as funcionalidades que cada banco não oferece. Não faz muito
> sentido. Por outro lado, uma camada de persistência que funcione bem com um
> "subset" dos bancos (ex: MongoDB e CouchDB) poderia ter resultados
> interessantes.
>
> É um projeto legal como pesquisa. Que tal tentar?
>
>
> --
> Carlos Ribeiro
> Consultoria em Projetos
> twitter: http://twitter.com/carribeiro
> blog: http://rascunhosrotos.blogspot.com
> mail: carribeiro@... <carribeiro%40gmail.com>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>



--
Ship ahoy! Hast seen the While Whale?
  - Melville's Captain Ahab


[As partes desta mensagem que não continham texto foram removidas]

Opa, bom dia :)

> Acho que ainda estamos muito "verdes" no assunto para dizer se vale ou não a
> pena investir em algo completamente novo. A idéia nem é usar ou deixar de
> usar o ORMs atuais - é explorar outras formas de trabalhar com persistência.

Acho que é porque temos motivações diferentes. Pros dois projetos onde
eu preciso disso hoje, a sua ideia não mudaria nada.

> Com certeza um "OPL" (object persistence layer) criado dentro de um

Eu usei o termo OPF por que outros autores já usam, mas gostei mais de
OPL também :) Enfim, o que importa é ter um meio comum para
persistência de objetos, não importando o tipo do repositório.

> paradigma key/value com map/reduce (ou seja, baseado no CouchDB) teria
> funções diferentes, e seria usado de uma forma diferente. Talvez isso possa

Como eu disse; pelo menos para os casos onde eu vejo a necessidade
disso no dia-a-dia *atual*, não seria o caso, pois em um projeto eu
uso ambos os paradigmas juntos (o CouchDB como complemento ao
relacional) e no outro eu não tenho relacional, mas integro com
webservice.

> ser útil e traga maior produtividade, ou maior facilidade de modelar certos
> tipos de sistemas; talvez não. Seria algo diferente. Agora, usar o CouchDB
> ou o Mongo (para ficar com os dois representantes mais populares do NoSQL
> hoje) com uma camada de "verniz relacional" talvez não faça bom uso dos
> recursos únicos desses sistemas.

Métodos como "get", "find", "save", "create" e "delete" não possuem
nada de relacional. Heranças também não, nem mixins, nem proxies, nem
caching. Nós estamos falando de persistência de objetos. O objeto
existe em Python e você vai persistí-lo em *algum* repositório.

Talvez o SQLAlchemy possa ser chamado assim porque você praticamente
trabalha com SQL orientado a objetos, mas as APIs do Django e o
SQLObject são mais próximas da OCL do que de DML/DDL. O problema delas
é o acoplamento ao relacional na estrutura interna... a carcaça tem
pouco a mexer (como ForeignKey, por exemplo).

> (se bem que, cá pra nós... pra fazer CRUD e gerar relatório não precisa de
> muita coisa mesmo :-))

Também acho que se um software fugir muito disso, ele não vai se
adequar nesse paradigma e deve ser tratado como caso a parte,
provavelmente não utilizando essa biblioteca (casos à parte
provavelmente nem usariam Django).

Mas não se trata de *CRUD*. Um ERP inteiro pode ser feito com
cadastros e transições de estados usando métodos comuns como "create"
e "save", creio que um CMS também. Nem por isso é só um CRUD.

Enfim, boa semana pra vocês!

--
Marinho Brandão (José Mário)
http://marinhobrandao.com/

Fala, pessoal. Tudo certo?
Seguinte, entre as 3 GUIs que andei dando uma olhada para desenvolver
aplicações (GTK, wx e Qt), me agradou mais a proposta do wx.
Bom, escolhida a GUI que mais me agradou, o negócio é desenvolver, correto?
Então, eu fiz uma tela de cadastro (bem simples) "no braço" só pra ver como
ficava. Herdei de wx.Frame, rodei o MainLoop e funcionou tudo certo.
Mas eu reparei que esse desenvolvimento "no braço" é muito custoso e requer
muito conhecimento da biblioteca e eu estou procurando um ambiente mais
"amigável" para o desenvolvimento em equipe.
Porém nenhuma ferramenta me agradou muito (wxGlade e o wxFormBuilder não
geram código em Python, wxDesigner possui licença comercial, os frameworks
wrappers parece que mais complicam do que simplificam o trabalho e tenho a
impressão de que a maioria está inativa).

Bom, eu queria saber de quem desenvolve com wxPython, quais ferramentas
utiliza para um ambiente mais "amigável" sem que o desenvolver tenha que
conhecer grande parte da biblioteca. Não estou procurando ferramentas que
gerem arquivos XMLs que tenham que ser interpretados depois, pois a minha
aplicação deve ser flexível a ponto de adicionar componentes dinamicamente.

Eu já estou pensando em desenvolver meu próprio wrapper... :)

Abraço.


[As partes desta mensagem que não continham texto foram removidas]

2010/2/7 Marinho Brandao <marinho@...>

> Bom, eu acho que isso manteria o problema como ele é hoje, e nesse
> caso não haveria motivo pra deixar de usar os ORMs que já existem :)
>

Acho que ainda estamos muito "verdes" no assunto para dizer se vale ou não a
pena investir em algo completamente novo. A idéia nem é usar ou deixar de
usar o ORMs atuais - é explorar outras formas de trabalhar com persistência.
Com certeza um "OPL" (object persistence layer) criado dentro de um
paradigma key/value com map/reduce (ou seja, baseado no CouchDB) teria
funções diferentes, e seria usado de uma forma diferente. Talvez isso possa
ser útil e traga maior produtividade, ou maior facilidade de modelar certos
tipos de sistemas; talvez não. Seria algo diferente. Agora, usar o CouchDB
ou o Mongo (para ficar com os dois representantes mais populares do NoSQL
hoje) com uma camada de "verniz relacional" talvez não faça bom uso dos
recursos únicos desses sistemas.

(se bem que, cá pra nós... pra fazer CRUD e gerar relatório não precisa de
muita coisa mesmo :-))

--
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: carribeiro@...


[As partes desta mensagem que não continham texto foram removidas]

Bom, eu acho que isso manteria o problema como ele é hoje, e nesse
caso não haveria motivo pra deixar de usar os ORMs que já existem :)

Em 7 de fevereiro de 2010 17:57, Vanderson Mota dos Santos
<vanderson.mota@...> escreveu:
>
>
>
> Acho mais interessante tentar descobrir qual é o mínimo necessário para
> criar uma API de modelos que sirva (por exemplo) para o Django, e que
> funcione com o CounchDB ou com o MongoDB. Seria uma forma de tentar tirar
> primeiro a bagagem relacional da cabeça, que praticamente impede de enxergar
> outro modo de fazer as coisas. Depois de acertar a mão com um banco NoSQL
> (de preferencia com um paradigma bem simples e claro, como key/value) aí sim
> eu veria se dava para generalizar. Eu prefiro chamar isso de OPL (Object
> Persistence Layer) em vez de framework, até porque estou pensando em algo
> mais leve mesmo. Mas ainda é tudo teoria. Também não sei se consigo tocar um
> projeto desses a essa altura...
>
> Acho que seria esse o caminho. Temos outro caso de bancos não relacionais,
> Os bancos orientados a objetos. Só que não estão tão "na moda".
>
> Em 7 de fevereiro de 2010 15:35, Carlos Ribeiro
<carribeiro@...>escreveu:
>
> > 2010/2/7 Marinho Brandao <marinho@...>
> >
> > > Se eu viesse a trabalhar em algo assim seria um framework de
> > > persistência agnóstico ao paradigma. Até porque não gostaria de estar
> > > preso ao NoSQL tanto quanto ao relacional. Existem possibilidades fora
> > > desse eixo, ou no meio do caminho, que poderiam ser interessantes.
> > >
> >
> > É aí que eu discordo. Se o framework for genérico demais, ou totalmente
> > agnóstico, fica difícil escrever o driver de cada banco - ele simplesmente
> > vai ter que fazer coisa demais.
> >
> > Acho mais interessante tentar descobrir qual é o mínimo necessário para
> > criar uma API de modelos que sirva (por exemplo) para o Django, e que
> > funcione com o CounchDB ou com o MongoDB. Seria uma forma de tentar tirar
> > primeiro a bagagem relacional da cabeça, que praticamente impede de
> > enxergar
> > outro modo de fazer as coisas. Depois de acertar a mão com um banco NoSQL
> > (de preferencia com um paradigma bem simples e claro, como key/value) aí
> > sim
> > eu veria se dava para generalizar. Eu prefiro chamar isso de OPL (Object
> > Persistence Layer) em vez de framework, até porque estou pensando em algo
> > mais leve mesmo. Mas ainda é tudo teoria. Também não sei se consigo tocar
> > um
> > projeto desses a essa altura...
> >
> > --
> > Carlos Ribeiro
> > Consultoria em Projetos
> > twitter: http://twitter.com/carribeiro
> > blog: http://rascunhosrotos.blogspot.com
> > mail: carribeiro@...
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
> > ------------------------------------
> >
> > ,----------------------------------------------------------.
> > | Antes de enviar um e-mail para o grupo leia: |
> > | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar |
> > | E se você é usuário do BOL lembre-se de cadastrar o |
> > | e-mail do grupo na lista branca do seu sistema anti-spam. |
> > `----------------------------------------------------------´Links do
> > Yahoo! Grupos
> >
> >
> >
>
> --
> Vanderson Mota dos Santos
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>


--
Marinho Brandão (José Mário)
http://marinhobrandao.com/

Acho mais interessante tentar descobrir qual é o mínimo necessário para
criar uma API de modelos que sirva (por exemplo) para o Django, e que
funcione com o CounchDB ou com o MongoDB. Seria uma forma de tentar tirar
primeiro a bagagem relacional da cabeça, que praticamente impede de enxergar
outro modo de fazer as coisas. Depois de acertar a mão com um banco NoSQL
(de preferencia com um paradigma bem simples e claro, como key/value) aí sim
eu veria se dava para generalizar. Eu prefiro chamar isso de OPL (Object
Persistence Layer) em vez de framework, até porque estou pensando em algo
mais leve mesmo. Mas ainda é tudo teoria. Também não sei se consigo tocar um
projeto desses a essa altura...

Acho que seria esse o caminho. Temos outro caso de bancos não relacionais,
Os bancos orientados a objetos. Só que não estão tão "na moda".

Em 7 de fevereiro de 2010 15:35, Carlos Ribeiro <carribeiro@...>escreveu:

> 2010/2/7 Marinho Brandao <marinho@...>
>
> > Se eu viesse a trabalhar em algo assim seria um framework de
> > persistência agnóstico ao paradigma. Até porque não gostaria de estar
> > preso ao NoSQL tanto quanto ao relacional. Existem possibilidades fora
> > desse eixo, ou no meio do caminho, que poderiam ser interessantes.
> >
>
> É aí que eu discordo. Se o framework for genérico demais, ou totalmente
> agnóstico, fica difícil escrever o driver de cada banco - ele simplesmente
> vai ter que fazer coisa demais.
>
> Acho mais interessante tentar descobrir qual é o mínimo necessário para
> criar uma API de modelos que sirva (por exemplo) para o Django, e que
> funcione com o CounchDB ou com o MongoDB. Seria uma forma de tentar tirar
> primeiro a bagagem relacional da cabeça, que praticamente impede de
> enxergar
> outro modo de fazer as coisas. Depois de acertar a mão com um banco NoSQL
> (de preferencia com um paradigma bem simples e claro, como key/value) aí
> sim
> eu veria se dava para generalizar. Eu prefiro chamar isso de OPL (Object
> Persistence Layer) em vez de framework, até porque estou pensando em algo
> mais leve mesmo. Mas ainda é tudo teoria. Também não sei se consigo tocar
> um
> projeto desses a essa altura...
>
> --
> Carlos Ribeiro
> Consultoria em Projetos
> twitter: http://twitter.com/carribeiro
> blog: http://rascunhosrotos.blogspot.com
> mail: carribeiro@...
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>
> ------------------------------------
>
> ,-----------------------------------------------------------.
> | Antes de enviar um e-mail para o grupo leia:              |
> | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar  |
> | E se você é usuário do BOL lembre-se de cadastrar o       |
> | e-mail do grupo na lista branca do seu sistema anti-spam. |
> `-----------------------------------------------------------´Links do
> Yahoo! Grupos
>
>
>


--
Vanderson Mota dos Santos


[As partes desta mensagem que não continham texto foram removidas]

2010/2/7 Marinho Brandao <marinho@...>

> Se eu viesse a trabalhar em algo assim seria um framework de
> persistência agnóstico ao paradigma. Até porque não gostaria de estar
> preso ao NoSQL tanto quanto ao relacional. Existem possibilidades fora
> desse eixo, ou no meio do caminho, que poderiam ser interessantes.
>

É aí que eu discordo. Se o framework for genérico demais, ou totalmente
agnóstico, fica difícil escrever o driver de cada banco - ele simplesmente
vai ter que fazer coisa demais.

Acho mais interessante tentar descobrir qual é o mínimo necessário para
criar uma API de modelos que sirva (por exemplo) para o Django, e que
funcione com o CounchDB ou com o MongoDB. Seria uma forma de tentar tirar
primeiro a bagagem relacional da cabeça, que praticamente impede de enxergar
outro modo de fazer as coisas. Depois de acertar a mão com um banco NoSQL
(de preferencia com um paradigma bem simples e claro, como key/value) aí sim
eu veria se dava para generalizar. Eu prefiro chamar isso de OPL (Object
Persistence Layer) em vez de framework, até porque estou pensando em algo
mais leve mesmo. Mas ainda é tudo teoria. Também não sei se consigo tocar um
projeto desses a essa altura...

--
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: carribeiro@...


[As partes desta mensagem que não continham texto foram removidas]

Opa,

> Ou seja: trata-se de mapear as operações sobre o objeto em operações no
> banco, que são expostas como SELCTs, UPDATEs, etc. Se o banco NoSQL em
> questão usar uma interface similar a SQL (como é o caso de alguns bancos)
> então a adaptação é fácil. Outros bancos (como o Couch) usam outro tipo de
> interface e talvez o mapeamento não seja direto.

Sim, mas este é um erro ao meu ver.

Vamos pegar o ORM do Django por exemplo: o backend do DBMS não faz o
papel de implementar o método persistente (save() ou delete(), por
exemplo)... ele funciona como uma espécie de fábrica de SQL, que
depois é usada pelo ORM num comando execute_sql de um cursor também
retornado por ele. Veja que só isso praticamente mata qualquer coisa
fora do relacional (SQL, execute_sql e cursor da DB API).

> No fundo, o que eu estou dizendo é que a API dos ORMs foi feita a partir de
> um conceito relacional; uma camada de persistência sobre um banco NoSQL
> talvez pudesse ser desenhada de outra forma, oferecendo outras primitivas.

Dos ORMs sim, até mesmo por sua própria definição.

Mas se estivermos falando de um "Framework de Persistência de Objetos"
  (OPF), então cada adapter de banco (no caso do Django, o backend)
teria de se virar para implementar o método (ou seja, nada de retornar
um SQL gerado mas sim, receber o objeto e o comando e implementar ao
seu próprio modo, no caso do relacional vai gerar um SQL e executar,
no caso do MongoDB vai criar um dicionário e persistir usando a
biblioteca pymongodb e assim por diante).

Porque a definição de "persistencia" não está acoplada a "mapeamento
objeto-relacional", ela pode até mesmo "persistir" no memcache ou em
arquivo puro, ou até mesmo simplesmente jogar fora (num fake),
whatever. Poderia enviar os objetos para um DAO e manipular tudo em
cache antes de persistir, poderia jogar pra um webservice... enfim,
são infinitas possibilidades, fora a facilidade de se criar plugins e
dispatcher/listeners em cima disso.

> Esse é outro ponto interessante, porque a idéia de usar um ORM,
> especialmente dentro de frameworks como Django, passa pelo conceito de
> Modelo. É a questão do MVC - o ORM suporta o modelo. Uma camada de

Que por sinal é um ponto polêmico e limitado, tanto que vez ou outra é
necessário apelar pro CouchDB ou pra uma tabela de campo+valor.

> persistência NoSQL teria que ser baseada em modelos, não devido à
> infra-estrutura subjacente do banco, mas porque a aplicação final é
> estruturada sobre os modelos. Talvez isso indique que o próprio MVC tenha
> que ser adaptado ou extendido para usar melhor os conceitos de bancos mais

Pode ser, mas concorda que de uma forma geral, "processamento de
dados" possui um certo vínculo a modelos na maioria dos casos? Se você
tem uma tela de "Enviar mensagem", que possui um form com os campos
"assunto", "destinatários" e "mensagem", logo você tem um modelo
mínimo com tais campos (alguns deles com tipo e tamanho definidos).

Isso pode ser extendido e tudo o mais, mas seria fora de propósito
você gravar num só namespace dados completamente diferentes com nomes
de campos conflitantes (i.e. "last_name" x "surname"). Casos que
quebram esse paradigma dificilmente vão se adaptar ao Admin/ModelForm
do Django, por exemplo.

Mesmo no CouchDB é importante você se basear em algo pra saber se
aquele documento é uma Mensagem, um Usuário, um Cliente, etc. No
MongoDB tem os namespaces que já te encaminham pra fazer isso também,
mesmo que seja livre.

> flexíveis. Um exemplo é o suporte a herança e mixins, que poderia ser feito
> com mecanismos diferentes dos usados em mapeadores relacionais (através de
> relações n:n, tabelas intermediárias, e coisas do tipo).

Pois é, mas esse seria o papel do adapter. A API se resumiria em
permitir heranças, mixins, proxies, etc. dentro da lógica do Python e
da Orientação a Objetos, e o adapter deveria se virar para implementar
isso na realidade dele. Claro que herança num Caché por exemplo
ofereceria um desafio à parte, mas enfim, um coelho de cada vez :P

E isso pode ser otimizado (i.e. os adapters de DBMS relacionais
poderiam herdar de uma classe abstrata em comum pra facilitar o que
fosse genérico).

> Acho complicado fazer algo 100% genérico. Veja bem: todos os bancos
> relacionais oferecem uma API parecida, e mesmo assim, as diferenças que
> ainda existem criam grandes dificuldades para os autores dos ORMs. Eu
> participei por algum tempo do desenvolvimento do SQLObject (há vários anos
> atrás), e me lembro do tipo de dor de cabeça que cada detalhe causa. Se você
> se limita a implementar o que é comum entre todas as alternativas, o
> resultado é limitado.
> O cenário de bancos NoSQL é muito amplo e representa paradigmas diferentes
> entre si. Não acho que seja possível implementar uma única API que aproveite
> bem os recursos de cada. O resultado teria que suportar TODAS as
> funcionalidades, e exigiria re-implementar no nível da camada de
> persistência as funcionalidades que cada banco não oferece. Não faz muito

O que não for genérico deve ser tratado de forma específica. Nada
impede que determinados bancos não suportem determinados recursos da
API. Isso é até comum.

O que fica chato é o cara usar MongoDB e se por ventura decidir no
futuro optar por CouchDB, ter de reescrever tudo. Veja como é o Django
no Google App Engine: fizeram uma puta gambiarra pra poder funcionar,
que fura aqui ou ali e a gente vai controlando à medida do possível.

Não estou falando mal, eu mesmo faço uso e estou satisfeito, mas é um
problema tanto em teoria quanto na prática. Ninguém gosta de
gambiarras. A gente faz uso delas quando é a única opção viável.

> sentido. Por outro lado, uma camada de persistência que funcione bem com um
> "subset" dos bancos (ex: MongoDB e CouchDB) poderia ter resultados
> interessantes.

Seria uma ideia interessante, mas limitaria quem trabalha com híbrido
de relacional + NoSQL, ou quem por ventura vier a migrar entre um e
outro... também limitaria frameworks como Django e web2py.

Se eu viesse a trabalhar em algo assim seria um framework de
persistência agnóstico ao paradigma. Até porque não gostaria de estar
preso ao NoSQL tanto quanto ao relacional. Existem possibilidades fora
desse eixo, ou no meio do caminho, que poderiam ser interessantes.

> É um projeto legal como pesquisa. Que tal tentar?

Acho que vai ter que entrar pra lista de ToDos de 2010 (aquela que
geralmente cai entre 25 de dezembro e 5 de janeiro)... rs

Abraços!

--
Marinho Brandão (José Mário)
http://marinhobrandao.com/

2010/2/7 Marinho Brandao <marinho@...>

> Opa,
>
> > Marinho, posso estar enganado, mas a API em grande parte serve para ...
> > expor funções relacionais para uso dentro da aplicação. Boa parte do
> código
> > serve para transformar acessos a properties em queries, fazer cache, etc.
> > Uma API NoSQL teria que ser diferente. Não faz sentido querer implementar
> a
> > mesma API, pois senão, além de refazer o código da API em si, ainda
> teríamos
> > que escrever funcionalidades que hoje são providas pelo banco. Certo? Ou
> > estou enganado (se estiver pode falar!!!) ?
>
> Bom, na maioria dos casos você tem funcionalidades semelhantes (obter
> objeto, obter lista filtrada por determinados atributos, criar,
> alterar, excluir, etc.) que diferem na sintaxe ou na forma, mas que
> possuem o mesmo papel na persistência.
>

Ou seja: trata-se de mapear as operações sobre o objeto em operações no
banco, que são expostas como SELCTs, UPDATEs, etc. Se o banco NoSQL em
questão usar uma interface similar a SQL (como é o caso de alguns bancos)
então a adaptação é fácil. Outros bancos (como o Couch) usam outro tipo de
interface e talvez o mapeamento não seja direto.

No fundo, o que eu estou dizendo é que a API dos ORMs foi feita a partir de
um conceito relacional; uma camada de persistência sobre um banco NoSQL
talvez pudesse ser desenhada de outra forma, oferecendo outras primitivas.

Quanto a transações e cache, pode variar de acordo com o banco, mas
> muitas vezes tem também recursos equivalentes e semelhantes.
>
> O que diferente mais é na normalização (ForeignKey por exemplo) e no
> modelo (geralmente em bancos NoSQL não existe modelo). Mas ainda
> assim, do ponto de vista de negócio, você tem um modelo mínimo
> implementado na maioria das classes persistentes.
>

Esse é outro ponto interessante, porque a idéia de usar um ORM,
especialmente dentro de frameworks como Django, passa pelo conceito de
Modelo. É a questão do MVC - o ORM suporta o modelo. Uma camada de
persistência NoSQL teria que ser baseada em modelos, não devido à
infra-estrutura subjacente do banco, mas porque a aplicação final é
estruturada sobre os modelos. Talvez isso indique que o próprio MVC tenha
que ser adaptado ou extendido para usar melhor os conceitos de bancos mais
flexíveis. Um exemplo é o suporte a herança e mixins, que poderia ser feito
com mecanismos diferentes dos usados em mapeadores relacionais (através de
relações n:n, tabelas intermediárias, e coisas do tipo).


> Creio que fora alguns detalhes, a diferença maior seria em permitir
> campos fora do modelo e no uso das bibliotecas de abstração de cada
> DBMS. Justamente pra quê? Pra você instanciar um objeto, alterar e
> salvar, e não mudar nada na sintaxe entre um DBMS e outro (aliás, se é
> um ORM, é porque mapeia do objeto para relacional... mas no caso de
> banco orientado a JSON ele mapearia objeto para documento, etc... mas
> veja que sempre é "Objeto" para alguma outra coisa, ou seja: no
> domínio do objeto, a API deveria ser a mesma, independente da forma de
> persistência.
>

Acho complicado fazer algo 100% genérico. Veja bem: todos os bancos
relacionais oferecem uma API parecida, e mesmo assim, as diferenças que
ainda existem criam grandes dificuldades para os autores dos ORMs. Eu
participei por algum tempo do desenvolvimento do SQLObject (há vários anos
atrás), e me lembro do tipo de dor de cabeça que cada detalhe causa. Se você
se limita a implementar o que é comum entre todas as alternativas, o
resultado é limitado.

O cenário de bancos NoSQL é muito amplo e representa paradigmas diferentes
entre si. Não acho que seja possível implementar uma única API que aproveite
bem os recursos de cada. O resultado teria que suportar TODAS as
funcionalidades, e exigiria re-implementar no nível da camada de
persistência as funcionalidades que cada banco não oferece. Não faz muito
sentido. Por outro lado, uma camada de persistência que funcione bem com um
"subset" dos bancos (ex: MongoDB e CouchDB) poderia ter resultados
interessantes.

É um projeto legal como pesquisa. Que tal tentar?

--
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: carribeiro@...


[As partes desta mensagem que não continham texto foram removidas]

Opa,

> Marinho, posso estar enganado, mas a API em grande parte serve para ...
> expor funções relacionais para uso dentro da aplicação. Boa parte do código
> serve para transformar acessos a properties em queries, fazer cache, etc.
> Uma API NoSQL teria que ser diferente. Não faz sentido querer implementar a
> mesma API, pois senão, além de refazer o código da API em si, ainda teríamos
> que escrever funcionalidades que hoje são providas pelo banco. Certo? Ou
> estou enganado (se estiver pode falar!!!) ?

Bom, na maioria dos casos você tem funcionalidades semelhantes (obter
objeto, obter lista filtrada por determinados atributos, criar,
alterar, excluir, etc.) que diferem na sintaxe ou na forma, mas que
possuem o mesmo papel na persistência.

Quanto a transações e cache, pode variar de acordo com o banco, mas
muitas vezes tem também recursos equivalentes e semelhantes.

O que diferente mais é na normalização (ForeignKey por exemplo) e no
modelo (geralmente em bancos NoSQL não existe modelo). Mas ainda
assim, do ponto de vista de negócio, você tem um modelo mínimo
implementado na maioria das classes persistentes.

Creio que fora alguns detalhes, a diferença maior seria em permitir
campos fora do modelo e no uso das bibliotecas de abstração de cada
DBMS. Justamente pra quê? Pra você instanciar um objeto, alterar e
salvar, e não mudar nada na sintaxe entre um DBMS e outro (aliás, se é
um ORM, é porque mapeia do objeto para relacional... mas no caso de
banco orientado a JSON ele mapearia objeto para documento, etc... mas
veja que sempre é "Objeto" para alguma outra coisa, ou seja: no
domínio do objeto, a API deveria ser a mesma, independente da forma de
persistência.

É o que eu penso.

--
Marinho Brandão (José Mário)
http://marinhobrandao.com/

2010/2/6 Marinho Brandao <marinho@...>

> Opa,
>
> > > Eu sinto falta de uma biblioteca de persistência no Python *que não
> > > seja presa* ao modelo ORM. De fato, as bibliotecas que eu conheço
> > > razoavelmente (SQLAlchemy, Django e SQLObject) estão *muito* presas ao
> > > relacional e à normalização. Chega a ser inviável adaptá-los a bancos
> > > NoSQL.
> > >
> >
> > Boa. Sinto falta de algo parecido também, e que possa trabalhar com
> > introspecção, mixins e coisas do tipo de forma natural.
> >
> > Mas a bem da verdade, serialização simples ou via JSON atende as
> > necessidades básicas (BEM básicas). Acho que é por isso que a coisa não
> > "decola".
>
> É, mas aí é que está: se você usa CouchDB e resolve migrar pra
> MongoDB, vai precisar mexer em tudo, mesmo ambos sendo JSON e
> denormalizados. Pior ainda se resolver migrar do MySQL para um banco
> NoSQL e assim por diante.
>
> Isso fora que uma biblioteca de abstração livre do relacional
> facilitaria muito a persistência em arquivos texto, XML, memória, etc.
> assim como plugins, regras de negócio e o tudo o mais. Quanto mais
> acoplado ao relacional, mais fica difícil (e quando necessário, cheio
> de gambiarras) pra fazer esse tipo de coisa.
>
> Pegue o ORM do Django, que tem uma API excelente, e dê uma olhada em
> como ele funciona por dentro: é completamente acoplado ao relacional.
> A solução mais sensata seria manter a API mas refazer todo o código.
> Mas aí vem: quem é o doido que vai fazer isso? hehe
>

Marinho, posso estar enganado, mas a API em grande parte serve para ...
expor funções relacionais para uso dentro da aplicação. Boa parte do código
serve para transformar acessos a properties em queries, fazer cache, etc.
Uma API NoSQL teria que ser diferente. Não faz sentido querer implementar a
mesma API, pois senão, além de refazer o código da API em si, ainda teríamos
que escrever funcionalidades que hoje são providas pelo banco. Certo? Ou
estou enganado (se estiver pode falar!!!) ?

--
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: carribeiro@...


[As partes desta mensagem que não continham texto foram removidas]

Opa,

> > Eu sinto falta de uma biblioteca de persistência no Python *que não
> > seja presa* ao modelo ORM. De fato, as bibliotecas que eu conheço
> > razoavelmente (SQLAlchemy, Django e SQLObject) estão *muito* presas ao
> > relacional e à normalização. Chega a ser inviável adaptá-los a bancos
> > NoSQL.
> >
>
> Boa. Sinto falta de algo parecido também, e que possa trabalhar com
> introspecção, mixins e coisas do tipo de forma natural.
>
> Mas a bem da verdade, serialização simples ou via JSON atende as
> necessidades básicas (BEM básicas). Acho que é por isso que a coisa não
> "decola".

É, mas aí é que está: se você usa CouchDB e resolve migrar pra
MongoDB, vai precisar mexer em tudo, mesmo ambos sendo JSON e
denormalizados. Pior ainda se resolver migrar do MySQL para um banco
NoSQL e assim por diante.

Isso fora que uma biblioteca de abstração livre do relacional
facilitaria muito a persistência em arquivos texto, XML, memória, etc.
assim como plugins, regras de negócio e o tudo o mais. Quanto mais
acoplado ao relacional, mais fica difícil (e quando necessário, cheio
de gambiarras) pra fazer esse tipo de coisa.

Pegue o ORM do Django, que tem uma API excelente, e dê uma olhada em
como ele funciona por dentro: é completamente acoplado ao relacional.
A solução mais sensata seria manter a API mas refazer todo o código.
Mas aí vem: quem é o doido que vai fazer isso? hehe

--
Marinho Brandão (José Mário)
http://marinhobrandao.com/