Re: [Python] "Go or Unladen Swallow? " Cosa ne pensate ?

2009-11-13 Per discussione luigi scarso
> Io lavoro in ambiente misto Erlang/Python: probabilmente ora non scriverei
> un servizio centrale in Python ma lo farei in Erlang, eventualmente con una
> serie di processi python in comunicazione (che a questo punto posso mettere
> ovunque, basta spawnare processi via ssh). Questo non vuol dire che non usi
> più Python: Erlang non mi sembra un linguaggio così general purpose da
> soppiantare Python. Sono convinto che usarli entrambi porti più vantaggi
> che scrivere programmi in C/C++/Java.


>
> Per pensare ad un servizio che possa scalare al mondo più che al
> linguaggio penserei all'infrastruttura più che al linguaggio in sé.
> Ultimamente ho dato un'occhiata ai sistemi di messaggistica (AMQP,
> RabbitMQ) e quelli mi sembrano un interessante componente per permettere ad
> un sistema di scalare (RabbitMQ si integra meravigliosamente con Erlang,
> Python e Javascript). Altro componente fondamentale di cui so poco è un
> database distribuito: purtroppo Mnesia non scala all'infinito e il mio caro
> PostgreSQL non è semplice da far scalare oltre il singolo server. Ho
> studiato poco sull'argomento, ma recentemente ho bookmarkato questo
>  che mi

> Solo un po' di pensieri in libertà.
Particolarmenti interessanti  per me, almeno in questo momento.
Che opinione hai di
http://couchdb.apache.org/docs/intro.html
?


-- 
luigi
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


[Python] CouchDB [Was: "Go or Unladen Swallow? " Cosa ne pensate ?]

2009-11-13 Per discussione Daniele Varrazzo
On Fri, 13 Nov 2009 10:25:27 +0100, luigi scarso 
wrote:

> Che opinione hai di
> http://couchdb.apache.org/docs/intro.html
> ?

Abbastanza nessuna, nel senso che so che è un progetto veramente ben
avviato, so che ha idee brillanti. Non sapevo fosse finito sotto l'ala dei
progetti apache, immagino sia un buon segno, in ogni caso aveva già diversi
mesi fa una bella comunità.

Non mi sono informato troppo perché non ho avuto mai (ancora) bisogno di
un "document-oriented database". Se già ho idealmente messo una croce sopra
ai db relazionali (idealmente! per ora tutto quello che faccio gira ancora
bene in un singolo server e non ho alcun progetto per cui una singola
istanza di PostgreSQL non mi possa bastare, per cui se posso mi tengo
stretta la completezza del DBMS "classico"), preferirei comunque avere un
database che mi permetta un accesso un po' più approfondito alle
informazioni che contiene, qualcosa tipo Cassandra (che neanche conosco
bene, ma mi sembra di averne intuito le possibilità di uso dopo aver letto
http://arin.me/code/wtf-is-a-supercolumn-cassandra-data-model).

Insomma, mi capita più spesso che non di aver a che fare con dati
strutturati, per cui non ho sentito mai troppo forte il richiamo di un DB
"documentale" (si può dire?). Magari poi è solo un marchio che si danno e
in soldoni finisce che ci sia poca differenza tra le innumerevoli forme di
storage scalabile che si stanno affacciando.

-- 
Daniele Varrazzo - Develer S.r.l. 
http://www.develer.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB [Was: "Go or Unladen Swallow? " Cosa ne pensate ?]

2009-11-13 Per discussione simozack
Il 13 novembre 2009 12.40, Daniele Varrazzo  ha scritto:

> Non mi sono informato troppo perché non ho avuto mai (ancora) bisogno di
> un "document-oriented database". Se già ho idealmente messo una croce sopra
> ai db relazionali (idealmente! per ora tutto quello che faccio gira ancora
> bene in un singolo server e non ho alcun progetto per cui una singola
> istanza di PostgreSQL non mi possa bastare, per cui se posso mi tengo
> stretta la completezza del DBMS "classico"), preferirei comunque avere un

Scusami l'ignoranza, ma PostgreSQL non è un db relazionale?

Ciao,
Simone
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB [Was: "Go or Unladen Swallow? " Cosa ne pensate ?]

2009-11-13 Per discussione Daniele Varrazzo
On Fri, 13 Nov 2009 13:41:49 +0100, simozack  wrote:
> Il 13 novembre 2009 12.40, Daniele Varrazzo  ha
scritto:
> 
>> Non mi sono informato troppo perché non ho avuto mai (ancora) bisogno
di
>> un "document-oriented database". Se già ho idealmente messo una croce
>> sopra
>> ai db relazionali (idealmente! per ora tutto quello che faccio gira
>> ancora
>> bene in un singolo server e non ho alcun progetto per cui una singola
>> istanza di PostgreSQL non mi possa bastare, per cui se posso mi tengo
>> stretta la completezza del DBMS "classico"), preferirei comunque avere
un
> 
> Scusami l'ignoranza, ma PostgreSQL non è un db relazionale?

Certo: forse mi sono spiegato male: PG è un DB relazionale, lo padroneggio
alla grande e si è rivelato adatto a tutti i sistemi a cui ho lavorato
finora e a cui lavoro attualmente.

Prendo atto che farlo scalare su più di una macchina sarebbe un problema e
se mi trovassi nella necessità di doverlo fare valuterei se non fosse il
caso di adottare un db diverso, "non classico", tra i tanti che ne stanno
uscendo in giro. Questo parallelamente alle strategie applicabili "dentro"
Postgres, che però vanno poco oltre la classica replica single-master
multi-slave.

Per ora non ho questa necessità: è più la solita curiosità di sapere dove
sta andando il mondo e farsi trovare pronti se la necessità dovesse bussare
alla porta.

-- 
Daniele Varrazzo - Develer S.r.l. 
http://www.develer.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB

2009-11-13 Per discussione luigi scarso
(ho cambiato l'oggetto)

2009/11/13 Daniele Varrazzo :
> On Fri, 13 Nov 2009 10:25:27 +0100, luigi scarso 
> wrote:
>
>> Che opinione hai di
>> http://couchdb.apache.org/docs/intro.html
>> ?
>
> Abbastanza nessuna, nel senso che so che è un progetto veramente ben
> avviato, so che ha idee brillanti. Non sapevo fosse finito sotto l'ala dei
> progetti apache, immagino sia un buon segno, in ogni caso aveva già diversi
> mesi fa una bella comunità.

l motivi per cui mi interessa

0) Erlang

1) siti
http://couchdb.apache.org/docs/intro.html
http://books.couchdb.org/relax/

2) python
http://pypi.python.org/pypi/CouchDB
http://pypi.python.org/pypi/couchdbkit/0.2.3

3)server
Ubuntu 9.10 server credo lo utilizzi di default per private cloud
http://www.ubuntu.com/cloud/private

Tutti punti che lo rendono molto interessante .

>
> Non mi sono informato troppo perché non ho avuto mai (ancora) bisogno di
> un "document-oriented database". Se già ho idealmente messo una croce sopra
> ai db relazionali (idealmente! per ora tutto quello che faccio gira ancora
> bene in un singolo server e non ho alcun progetto per cui una singola
> istanza di PostgreSQL non mi possa bastare, per cui se posso mi tengo
> stretta la completezza del DBMS "classico"),
Capisco perfettamente.

>preferirei comunque avere un
> database che mi permetta un accesso un po' più approfondito alle
> informazioni che contiene, qualcosa tipo Cassandra (che neanche conosco
> bene, ma mi sembra di averne intuito le possibilità di uso dopo aver letto
> http://arin.me/code/wtf-is-a-supercolumn-cassandra-data-model).
Un link in più
http://www.oracle.com/technology/documentation/berkeley-db/xml/ref_xml/xml_win/bin.html
Non è immediato usarlo -- io pensavo di si.
Ovviamente c'è python .


>
> Insomma, mi capita più spesso che non di aver a che fare con dati
> strutturati, per cui non ho sentito mai troppo forte il richiamo di un DB
> "documentale" (si può dire?).
Si -- per me.
Non riesco però a definirlo bene,
nel  senso di distinguerlo come modello da quello relazionale.

-- 
luigi
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] "Go or Unladen Swallow? " Cosa ne pensate ?

2009-11-13 Per discussione luigi scarso
2009/11/12 Marco Mariani :
> e' normale che si attivino le difese immunitarie
> antitroll.
Hm.
Non mi è chiaro cosa  intendi dire.


-- 
luigi
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB [Was: "Go or Unladen Swallow? " Cosa ne pensate ?]

2009-11-13 Per discussione luigi scarso
2009/11/13 Daniele Varrazzo :
> On Fri, 13 Nov 2009 13:41:49 +0100, simozack  wrote:
>> Il 13 novembre 2009 12.40, Daniele Varrazzo  ha
> scritto:
>>
>>> Non mi sono informato troppo perché non ho avuto mai (ancora) bisogno
> di
>>> un "document-oriented database". Se già ho idealmente messo una croce
>>> sopra
>>> ai db relazionali (idealmente! per ora tutto quello che faccio gira
>>> ancora
>>> bene in un singolo server e non ho alcun progetto per cui una singola
>>> istanza di PostgreSQL non mi possa bastare, per cui se posso mi tengo
>>> stretta la completezza del DBMS "classico"), preferirei comunque avere
> un
>>
>> Scusami l'ignoranza, ma PostgreSQL non è un db relazionale?
>
hmm ... quasi.

http://www.postgresql.org/about/
PostgreSQL is a powerful, open source object-relational database system.


http://en.wikipedia.org/wiki/Object-relational_database
An object-relational database (ORD), or object-relational database
management system (ORDBMS), is a database management system (DBMS)
similar to a relational database, but with an object-oriented database
model: objects, classes and inheritance are directly supported in
database schemas and in the query language. In addition, it supports
extension of the data model with custom data-types and methods.
Example of a Object-Oriented Database Model.[1]

An object-relational database can be said to provide a middle ground
between relational databases and object-oriented databases (OODBMS).
In object-relational databases, the approach is essentially that of
relational databases: the data resides in the database and is
manipulated collectively with queries in a query language; at the
other extreme are OODBMSes in which the database is essentially a
persistent object store for software written in an object-oriented
programming language, with a programming API for storing and
retrieving objects, and little or no specific support for querying.


> si è rivelato adatto a tutti i sistemi a cui ho lavorato
> finora e a cui lavoro attualmente.

Idem -- quasi un' assioma.

-- 
luigi
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB [Was: "Go or Unladen Swallow? " Cosa ne pensate ?]

2009-11-13 Per discussione Manlio Perillo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Daniele Varrazzo ha scritto:
> [...]
> Certo: forse mi sono spiegato male: PG è un DB relazionale, lo padroneggio
> alla grande e si è rivelato adatto a tutti i sistemi a cui ho lavorato
> finora e a cui lavoro attualmente.
> 
> Prendo atto che farlo scalare su più di una macchina sarebbe un problema e
> se mi trovassi nella necessità di doverlo fare valuterei se non fosse il
> caso di adottare un db diverso, "non classico", tra i tanti che ne stanno
> uscendo in giro. Questo parallelamente alle strategie applicabili "dentro"
> Postgres, che però vanno poco oltre la classica replica single-master
> multi-slave.
> 

Non direi che vanno "poco" oltre la replica single-master multi-slave.

La pagina
http://www.postgresql.org/docs/8.4/interactive/high-availability.html
indica alcune alternative.

Di queste la "Statement-Based Replication Middleware" mi sembra molto
interessate, e ci sono implementazioni disponibili come Pgpool-II.

Se fai pochi INSERT/UPDATE/DELETE e molti SELECT dovrebbe essere la
soluzione ideale.


> [...]


Ciao  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkr9Z6UACgkQscQJ24LbaUQj0QCbB/9h3NpAq85QSyjxUbw51DRr
B0cAnifMZgqwpKlrISCqCS6hpGjWM6Xm
=qXiP
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB

2009-11-13 Per discussione Lawrence Oluyede
2009/11/13 luigi scarso :
> (ho cambiato l'oggetto)

così ora si frammentano ulteriormente i thread :-(
> Un link in più
> http://www.oracle.com/technology/documentation/berkeley-db/xml/ref_xml/xml_win/bin.html
> Non è immediato usarlo -- io pensavo di si.

Ci ho buttato via 3 mesi della mia vita due anni fa su quel coso. È la
cosa più tremenda che Oracle e BDB
potessero partorire. Lascia perdere :-)

-- 
Lawrence Oluyede
[eng] http://oluyede.org - http://twitter.com/lawrenceoluyede
[ita] http://neropercaso.it - http://twitter.com/rhymes
[flickr] http://www.flickr.com/photos/rhymes
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB

2009-11-13 Per discussione luigi scarso
2009/11/13 Lawrence Oluyede :


>
> Ci ho buttato via 3 mesi della mia vita due anni fa su quel coso. È la
> cosa più tremenda che Oracle e BDB
> potessero partorire. Lascia perdere :-)

Ho scritto infatti
"Non è immediato usarlo -- io pensavo di si."
a significare che avere il quadro completo subito non è immediato,
si rischia di sottovalutare  certi aspetti.

Lo uso per un  progetto e  con  python + lxml ,
non è ne tremendo ne disastroso ne ho buttato via tempo.


Però CouchDB + python + lxml
già oggi forse può essere più adeguato per quel progetto,
per questo mi interessa.



-- 
luigi
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB [Was: "Go or Unladen Swallow? " Cosa ne pensate ?]

2009-11-13 Per discussione Daniele Varrazzo
On Fri, 13 Nov 2009 14:35:36 +0100, luigi scarso 
wrote:

>>> Scusami l'ignoranza, ma PostgreSQL non è un db relazionale?
>>
> hmm ... quasi.
> 
> http://www.postgresql.org/about/
> PostgreSQL is a powerful, open source object-relational database system.
> 
> 
> http://en.wikipedia.org/wiki/Object-relational_database
> An object-relational database (ORD), or object-relational database
> management system (ORDBMS), is a database management system (DBMS)
> similar to a relational database, but with an object-oriented database
> model: objects, classes and inheritance are directly supported in
> database schemas and in the query language. 

No, lasciamo perdere queste definizioni: sono solo da marchettari per
cavalcare quella che in un certo momento era la cresta dell'onda. Direi che
chi ha gestito l'immagine di PG negli anni 90 di queste cappellate ne ha
fatte diverse: pensa che la prima versione si chiamava Postgres95 (chi
cazzo l'avrebbe mai usato nel 96??). E "PostgreSQL" non conosco due persone
al mondo che lo pronuncino allo stesso modo, per non parlare
dell'irrisorietà che ha il linguaggio SQL nel sistema nel complesso (ma che
appunto anni fa era di moda: il "Postgres" originale non era utilizzava SQL
ma su un linguaggio chiamato QUEL. No, l'autore non è Guzzanti).

Quanto sia orientato agli oggetti PG è un'altra cosa ampiamente
trascurabile ma una parola graziosa per stampare brochure: hai una sorta di
ereditarietà tra tabelle che si sarebbe potuta replicare benissimo con
altre tecniche, limitata (es. non si riescono a fare query polimorfiche in
maniera efficiente, neanche limitandosi alla classe di base) e che non
aiuta a superare l'OO mismatch con i linguaggi di programmazione.

Postgres è un fantastico database relazionale, ma le sue incursioni nel
mondo OO o XML sono solo featurismi secondo me abbastanza poco profondi da
essere fondamentali e per fortuna facilmente evitabili per chi non ne ha
bisogno.

-- 
Daniele Varrazzo - Develer S.r.l. 
http://www.develer.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB [Was: "Go or Unladen Swallow? " Cosa ne pensate ?]

2009-11-13 Per discussione Daniele Varrazzo
On Fri, 13 Nov 2009 15:05:26 +0100, Manlio Perillo
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Daniele Varrazzo ha scritto:
>> [...]
>> Certo: forse mi sono spiegato male: PG è un DB relazionale, lo
>> padroneggio
>> alla grande e si è rivelato adatto a tutti i sistemi a cui ho lavorato
>> finora e a cui lavoro attualmente.
>> 
>> Prendo atto che farlo scalare su più di una macchina sarebbe un
problema
>> e
>> se mi trovassi nella necessità di doverlo fare valuterei se non fosse
il
>> caso di adottare un db diverso, "non classico", tra i tanti che ne
stanno
>> uscendo in giro. Questo parallelamente alle strategie applicabili
>> "dentro"
>> Postgres, che però vanno poco oltre la classica replica single-master
>> multi-slave.
>> 
> 
> Non direi che vanno "poco" oltre la replica single-master multi-slave.
> 
> La pagina
> http://www.postgresql.org/docs/8.4/interactive/high-availability.html
> indica alcune alternative.
> 
> Di queste la "Statement-Based Replication Middleware" mi sembra molto
> interessate, e ci sono implementazioni disponibili come Pgpool-II.
> 
> Se fai pochi INSERT/UPDATE/DELETE e molti SELECT dovrebbe essere la
> soluzione ideale.

Mi sembrano tutte soluzioni che pongono parecchia pressione sul DBAdmin e
più delle pezze che una soluzione definitiva a
load-balancing/high-availability. In quali di quelle indicate aggiungere un
nodo ad un cluster è un'operazione trasparente? Se sono basate su PG devono
avere in qualche modo una replica almeno parziale (shard) di tutto il
dataset (altrimenti addio integrità referenziale). Noi abbiamo un db
relativamente piccolo, pochi tera e la tabella più grande di 60M di record,
e fare una replica tra due macchine già ci costerebbe una giornata buona.

Queste sono appunto misure disponibili e da prendere in considerazione, ma
se devo anche pensare (come suggerito per la "Statement-Based Replication
Middleware", che come dici sembra la più promettente) a "Also, care must be
taken that all transactions either commit or abort on all servers, perhaps
using two-phase commit", allora mi salta la maggior parte dell'eleganza di
usare PG.

Per ottenere certe feature ci sono delle rinunce da fare alla completezza
del modello relazionale, che non può essere "shared nothing". Puoi
rinunciare alle proprietà ACID (o insistere a usarle sebbene nella maniera
più scomoda della 2PC), ma volendo puoi anche decidere di rinunciare ai
Join e usare HBase/Cassandra. O alla struttura del tutto e usare
MongoDB/CouchDB. O agli oggetti del tutto e usare Redis/Tokio Cabinet.

Non me lo sono mica sposato, l'elefante :) Se lo devo frustare preferisco
farmi un'analisi seria e decidere se ci sono strumenti migliori per il
compito che dovessi avere.

-- 
Daniele Varrazzo - Develer S.r.l. 
http://www.develer.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB [Was: "Go or Unladen Swallow? " Cosa ne pensate ?]

2009-11-13 Per discussione Daniele Varrazzo
On Fri, 13 Nov 2009 17:04:24 +0100, Daniele Varrazzo 
wrote:

> [...] Noi abbiamo un db
> relativamente piccolo, pochi tera 

...esagerato! volevo dire pochi giga (non pochissimi, alcune decine).

-- 
Daniele Varrazzo - Develer S.r.l. 
http://www.develer.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB

2009-11-13 Per discussione Lawrence Oluyede
2009/11/13 luigi scarso :
>
> Ho scritto infatti
> "Non è immediato usarlo -- io pensavo di si."
> a significare che avere il quadro completo subito non è immediato,
> si rischia di sottovalutare  certi aspetti.
>
> Lo uso per un  progetto e  con  python + lxml ,
> non è ne tremendo ne disastroso ne ho buttato via tempo.

Io ho avuto una pessima esperienza, ma ovviamente dipende
dall'esigenza di partenza ;-)



-- 
Lawrence Oluyede
[eng] http://oluyede.org - http://twitter.com/lawrenceoluyede
[ita] http://neropercaso.it - http://twitter.com/rhymes
[flickr] http://www.flickr.com/photos/rhymes
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB [Was: "Go or Unladen Swallow? " Cosa ne pensate ?]

2009-11-13 Per discussione Lawrence Oluyede
2009/11/13 Daniele Varrazzo :
> Postgres è un fantastico database relazionale, ma le sue incursioni nel
> mondo OO o XML sono solo featurismi secondo me abbastanza poco profondi da
> essere fondamentali e per fortuna facilmente evitabili per chi non ne ha
> bisogno.

In effetti il suo supporto all'XML andrebbe non poco migliorato :-(

-- 
Lawrence Oluyede
[eng] http://oluyede.org - http://twitter.com/lawrenceoluyede
[ita] http://neropercaso.it - http://twitter.com/rhymes
[flickr] http://www.flickr.com/photos/rhymes
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB [Was: "Go or Unladen Swallow? " Cosa ne pensate ?]

2009-11-13 Per discussione Daniele Varrazzo
On Fri, 13 Nov 2009 17:08:31 +0100, Lawrence Oluyede 
wrote:
> 2009/11/13 Daniele Varrazzo :
>> Postgres è un fantastico database relazionale, ma le sue incursioni nel
>> mondo OO o XML sono solo featurismi secondo me abbastanza poco profondi
>> da
>> essere fondamentali e per fortuna facilmente evitabili per chi non ne
ha
>> bisogno.
> 
> In effetti il suo supporto all'XML andrebbe non poco migliorato :-(

...o valutare se un DB orientato ai documenti non possa essere uno
strumento migliore per questo compito.

-- 
Daniele Varrazzo - Develer S.r.l. 
http://www.develer.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB [Was: "Go or Unladen Swallow? " Cosa ne pensate ?]

2009-11-13 Per discussione Lawrence Oluyede
2009/11/13 Daniele Varrazzo :
>
> ...o valutare se un DB orientato ai documenti non possa essere uno
> strumento migliore per questo compito.

eh eh il problema nasce anche dal fatto che magari, come nel nostro
caso, l'xml è parte integrante dell'applicazione relazionale e si
estraggono informazioni da esso. Avere due DB sarebbe un casino e per
la mole di dati non ne vale la pena. Alcune cose le facciamo estraendo
l'xml e elaborandolo con lxml :-)

-- 
Lawrence Oluyede
[eng] http://oluyede.org - http://twitter.com/lawrenceoluyede
[ita] http://neropercaso.it - http://twitter.com/rhymes
[flickr] http://www.flickr.com/photos/rhymes
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB [Was: "Go or Unladen Swallow? " Cosa ne pensate ?]

2009-11-13 Per discussione luigi scarso
2009/11/13 Daniele Varrazzo :
> No, lasciamo perdere queste definizioni: sono solo da marchettari per
> cavalcare quella che in un certo momento era la cresta dell'onda.


Le persone che conosco e che usano Postgres hanno tutte una
opinione favorevole; in questi anni Postgres
non mi ha mai dato impressioni negative,
neppure da un punto di vista comunicativo.
Con python si integra bene.
Penso che chi mantiene il sito sia sufficientemente
competente per sapere quello che scrive, presentando Postgres.

Al solito sta ad una persona valutare le caratteristiche:
per esempio, parlando di XML,
non mi è mai venuto in mente di usare
pg  come  DB orientato ai documenti a motivo del suo supporto XML --
ed onestamente a nessuno
di quelli che conosco -- anche se questo supporto l'ho visto via via
crescere e maturare.

Invece come supporto per la  gestione dei miei  workflow whatever_to_pdf
affiancato eventualmente da (ad esempio) python + lxml, o
xsltproc xmllint , beh si, lo trovo valido.



-- 
luigi
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB

2009-11-13 Per discussione luigi scarso
2009/11/13 Lawrence Oluyede :
> 2009/11/13 luigi scarso :
>>
>> Ho scritto infatti
>> "Non è immediato usarlo -- io pensavo di si."
>> a significare che avere il quadro completo subito non è immediato,
>> si rischia di sottovalutare  certi aspetti.
>>
>> Lo uso per un  progetto e  con  python + lxml ,
>> non è ne tremendo ne disastroso ne ho buttato via tempo.
>

Io ho avuto una pessima esperienza, ma ovviamente dipende
dall'esigenza di partenza ;-)

Si -- ma quello che mi sfugge è perchè .
La documentazione mi pare ok;
il codice disponibile;
BDB consolidato;
XML noto;
XQuery noto;
Python (o Java ,o C++) validi.

Insomma perchè hai avuto una pessima eperienza  ?

-- 
luigi
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB

2009-11-13 Per discussione Lawrence Oluyede
2009/11/13 luigi scarso :
>
> Insomma perchè hai avuto una pessima eperienza  ?

Perché gestirlo in una applicazione massivamente concorrente non è
facile essendo un DB in process.
Ai tempi PostgreSQL non aveva il supporto XML e i DB documentali che
sono trendy ora non c'erano o stavano nascendo.
Ci sembrava il più solido ma non andava bene per i nostri requisiti

-- 
Lawrence Oluyede
[eng] http://oluyede.org - http://twitter.com/lawrenceoluyede
[ita] http://neropercaso.it - http://twitter.com/rhymes
[flickr] http://www.flickr.com/photos/rhymes
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB

2009-11-13 Per discussione luigi scarso
2009/11/13 Lawrence Oluyede :
> così ora si frammentano ulteriormente i thread :-(
Si, in generale non è una buona mossa.
L'ho fatto perchè per quanto mi riguarda "GO.." è chiuso .
Concordo con
http://www.python.org/dev/peps/pep-3003/


-- 
luigi
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB

2009-11-13 Per discussione luigi scarso
2009/11/13 Lawrence Oluyede :
> 2009/11/13 luigi scarso :
>>
>> Insomma perchè hai avuto una pessima eperienza  ?
>

> Perché gestirlo in una applicazione massivamente concorrente non è
> facile essendo un DB in process.
Si, ma è una affermazione piuttosto generica .

Voglio dire:

*) hai una
applicazione ad alto grado di concorrenza ,che immagino conosci nelle specifiche

*) hai un db basato su BDB che gestisce documenti in XML in modo
efficiente -- ma non è un dbms come postgres.

*) presuppongo python -- solo perchè la ml è python.it :-)

Qual'è stato il punto critico ?

Ad esempio posso dirti che bisogna prestare attenzione al documento
del db , alle query e l'indicizzazione.
Può essere vantaggioso usare dbxml come contenitore generico, per
piccoli documenti e poco strutturati;
Ma è sicuramente sbagliato usare dbxml come
contenitore generico per grandi  documenti,  molto strutturati, con
frequenti modifiche, con un alto grado di concorrenza.

Nel mio caso, ho piccoli documenti abbastanza strutturati, di due tipi ;
ho praticamente solo letture ed inserimenti;
ho un grado di concorrenza basso, ed un'esigenza di servizio continuativo.
Le query sono al 80% ottimizzate, le rimanenti sono estemporanee.
E' stato scelto XML perchè il modello del documento -- uno standard de facto
soddisfa i requisiti richiesti, essenzialmete da ponte tra il modello
del documento del cliente
e quello del ns gestionale .



-- 
luigi
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB [Was: "Go or Unladen Swallow? " Cosa ne pensate ?]

2009-11-13 Per discussione Carlo C8E Miron
2009/11/13 Daniele Varrazzo :
> On Fri, 13 Nov 2009 17:08:31 +0100, Lawrence Oluyede 
> wrote:
>> 2009/11/13 Daniele Varrazzo :
>>> Postgres è un fantastico database relazionale, ma le sue incursioni nel
>>> mondo OO o XML sono solo featurismi secondo me abbastanza poco profondi
>>> da
>>> essere fondamentali e per fortuna facilmente evitabili per chi non ne
> ha
>>> bisogno.
>>
>> In effetti il suo supporto all'XML andrebbe non poco migliorato :-(
>
> ...o valutare se un DB orientato ai documenti non possa essere uno
> strumento migliore per questo compito.

La cosa curiosa e` che couchdb ha abbandonato gia` da un pezzo l'xml
in favore di json ;)

©
-- 
Carlo C8E Miron
We All Hate XML Solution Architect™






___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB

2009-11-13 Per discussione Lawrence Oluyede
2009/11/13 luigi scarso :
> *) hai una
> applicazione ad alto grado di concorrenza ,che immagino conosci nelle 
> specifiche
>
> *) hai un db basato su BDB che gestisce documenti in XML in modo
> efficiente -- ma non è un dbms come postgres.
>
> *) presuppongo python -- solo perchè la ml è python.it :-)
>
> Qual'è stato il punto critico ?

L'applicazione è client server, l'applicazione è concorrente
(parallela a dire il vero), il client e il server non girano
necessariamente sulla stessa macchina, ergo un db in process non è la
scelta migliore del mondo. Aggiungi il fatto che già usavamo 2 db
relazionali (per mille altre applicazioni) e che poco dopo postgres ha
aggiunto il supporto XML. Per cui si decise di lasciar perdere
OracleDB. Molto più comodo così credimi (anche perché sfruttiamo a
gratis il know how sui due db relazionali, le procedure di backup ecc
ecc).

Ripeto: dipende dalle esigenze, mi sembra che nel tuo caso BDBXML sia
una scelta corretta

-- 
Lawrence Oluyede
[eng] http://oluyede.org - http://twitter.com/lawrenceoluyede
[ita] http://neropercaso.it - http://twitter.com/rhymes
[flickr] http://www.flickr.com/photos/rhymes
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB [Was: "Go or Unladen Swallow? " Cosa ne pensate ?]

2009-11-13 Per discussione Lawrence Oluyede
2009/11/13 Carlo C8E Miron :
>
>
> La cosa curiosa e` che couchdb ha abbandonato gia` da un pezzo l'xml
> in favore di json ;)

Sì, tipo il terzo giorno di sviluppo :P

-- 
Lawrence Oluyede
[eng] http://oluyede.org - http://twitter.com/lawrenceoluyede
[ita] http://neropercaso.it - http://twitter.com/rhymes
[flickr] http://www.flickr.com/photos/rhymes
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB

2009-11-13 Per discussione luigi scarso
2009/11/13 Lawrence Oluyede :
>> Qual'è stato il punto critico ?
>
> L'applicazione è client server, l'applicazione è concorrente
> (parallela a dire il vero), il client e il server non girano
> necessariamente sulla stessa macchina, ergo un db in process non è la
> scelta migliore del mondo. Aggiungi il fatto che già usavamo 2 db
> relazionali (per mille altre applicazioni) e che poco dopo postgres ha
> aggiunto il supporto XML. Per cui si decise di lasciar perdere
> OracleDB. Molto più comodo così credimi (anche perché sfruttiamo a
> gratis il know how sui due db relazionali, le procedure di backup ecc
> ecc).
Tutto quello che dici è ragionevole,
discutibile nel senso proprio del termine, ovvero che offre validi
spunti di discussione,
ma non individuo uno punto critico  di db xml, ne db xml + python
che giustifichino
>È la
>cosa più tremenda che Oracle e BDB
>potessero partorire
Mi sembra più una questione di analisi/progettazione che altro.

-- 
luigi
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB [Was: "Go or Unladen Swallow? " Cosa ne pensate ?]

2009-11-13 Per discussione luigi scarso
2009/11/13 Carlo C8E Miron :
> La cosa curiosa e` che couchdb ha abbandonato gia` da un pezzo l'xml
> in favore di json ;)
Non sono rimasto particolarmente colpito da questo aspetto.
E' noto che XML non è la panacea di tutti i mali,
è vero che un documento testuale
in formato xml in generale non è una cattiva cosa,
è vero che un export
in formato xml *può* essere meglio di uno in formato txt,...

Ma sono tutte osservazioni banali.

Per me, la cosa interessante
è che non mi sembra una moda del momento,
e che python è presente.


PS
interessante
We All Hate XML Solution Architect™,
cos'è ?


-- 
luigi
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB

2009-11-13 Per discussione Lawrence Oluyede
2009/11/13 luigi scarso :
>>È la
>>cosa più tremenda che Oracle e BDB
>>potessero partorire
> Mi sembra più una questione di analisi/progettazione che altro.

Eddai Luca, è una frase di getto, non mi sono proprio trovato bene con
quel tool, tutto qui. Chiusa la discussione :-)

-- 
Lawrence Oluyede
[eng] http://oluyede.org - http://twitter.com/lawrenceoluyede
[ita] http://neropercaso.it - http://twitter.com/rhymes
[flickr] http://www.flickr.com/photos/rhymes
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB

2009-11-13 Per discussione Carlo C8E Miron
2009/11/13 Lawrence Oluyede :
> 2009/11/13 luigi scarso :
 ^
>> Mi sembra più una questione di analisi/progettazione che altro.
>
> Eddai Luca,

Con chi stai parlando, Law?

©
-- 
Carlo C8E Miron
We All Love Law Solution Architect™






___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB

2009-11-13 Per discussione Lawrence Oluyede
On Fri, Nov 13, 2009 at 9:09 PM, Carlo C8E Miron  wrote:
>> Eddai Luca,
>        
> Con chi stai parlando, Law?
>

haahaha :D

-- 
Lawrence Oluyede
[eng] http://oluyede.org - http://twitter.com/lawrenceoluyede
[ita] http://neropercaso.it - http://twitter.com/rhymes
[flickr] http://www.flickr.com/photos/rhymes
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB

2009-11-13 Per discussione luigi scarso
2009/11/13 Lawrence Oluyede :

> Eddai Luca, è una frase di getto, non mi sono proprio trovato bene con
> quel tool, tutto qui.
Mah, non so..mi pareva che il thread "GO.." fosse dedicato alle sparate.

Insomma se scrivo nella ml "non usare",
mi pare chiaro che intendo qualcosa di diverso da "non mi sono trovato bene" .

E... si, credo sia anche una questione generale di linguaggio di questa ml
-- inaspettata, visti  i profili dei partecipanti.


-- 
luigi
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB

2009-11-13 Per discussione Lawrence Oluyede
2009/11/13 luigi scarso :
>
> E... si, credo sia anche una questione generale di linguaggio di questa ml
> -- inaspettata, visti  i profili dei partecipanti.

Boh io non ho nulla contro Go o contro XML. Mi sai che ne stai facendo
un problema per
trascinare la discussione che mi sembra più che morta.

-- 
Lawrence Oluyede
[eng] http://oluyede.org - http://twitter.com/lawrenceoluyede
[ita] http://neropercaso.it - http://twitter.com/rhymes
[flickr] http://www.flickr.com/photos/rhymes
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] "Go or Unladen Swallow? " Cosa ne pensate ?

2009-11-13 Per discussione Enrico Franchi


On Nov 12, 2009, at 6:22 PM, luigi scarso wrote:


OK,  qual'e la tua osservazione in merito ad XML


Che in generale e' un overkill. Come formato human readable fa un po'  
schifo,
come formato di macchina in generale ci sono alternative piu' compatte  
ed

efficienti adatte per la specifica soluzione.






Ed ancora : perchè parli di librerie ?
Io parlo di linguaggio di programmazione , Python, meglio  CPython .
Le librerie sono una storia diversa.
Tratta il compilatore/interprete allo stesso modo. Mi pare ovvio.

Io preferisco mantenere distinti in termini
librerie e linguaggio di programmazione .


Purtroppo il problema e' assolutamente uniforme. Dal momento che nel  
caso
il problema riguarda semplicemente la versione di un complatore+vm. E  
non mi
vengono in mente motivi per cui dovresti avere policy per la gestione  
per
l'upgrade del compilatore/vm piu' lasche di quelle che hai per la  
gestione delle

librerie.


Si, ma non sono uno sviluppatore  Zope ne sono uno sviluppatore Plone.
Ho usato ed uso entrambi, ma non sono uno sviluppatore.
E Zope non è una mia fisima, per rimanere coerente con questo thread e
neppure Plone.


E chi ha detto che Zope sia una fisima? E' un progetto.
E' una fisima il tuo problema  con le versioni di Python.

E il problema di Python sarebbe? Che fanno una nuova versione e tu  
non

puoi non usarla?

Si, una mia fisima


Adesso tu la prenderai male, ti prego non offerti: queste pero' sono  
cose che

riguardano piu' la psicoanalisi che le mailing list tecniche. :)

BTW, vorresti che mi mettessi a fare il grammar troll come un tal  
Scarso

che gira per questa ML?

Non so cosa intendi per grammar troll.


Ho idea che google potrebbe esserti di aiuto.

Per il resto, dal momento che i programmi Python 2.4 girano su  
Python 2.6...

dove sarebbe il problema?

Non credo sia una completamente vero.


Questa e' la policy per la backward compatibility di Python.
http://www.python.org/dev/peps/pep-0387/

Direi che questo vuole dire che se non vai a dipendere (per necessaria  
o malsana

scelta tua) da qualcosa di privato, sei compatibile.


No. E' una libreria, forse un framework. Che mi frega?

zope.interface , cfr sotto .


Zope.interface funziona sicuramente con Python 2.5.
Lo ho appena importato con Python 2.6 (e quello che ci gira sopra  
funziona).

Mi sento di affermare che quel pezzo di ZCA funziona.

Ergo, che mi frega.

Tornando sotto: ZCA e' comunque un framework. Ammesso e non concesso
che non funzionino con Python 2.6... che c'entra con il linguaggio?

Per stare nel mondo reale... ZCA non ha nessun problema con Python  
2.6. Siamo
consapevoli di questo? Per cui di fatto ZCA non ha problemi (come il  
98% del software)

con le nuove versioni.

BTW, loro medesimi suggeriscono di dare un occhio a virtualenv.


Forse Python Component Architecture. poteva essere di aiuto qui ?
http://blog.labix.org/2009/05/15/class-member-access-control-enforcement-vs-convention

Sono completamente in disaccordo con l'autore.

Perché ?


Lungo e OT. Se vuoi parlarne, nuovo thread. Non e' detto che  
partecipero'.

Comunque per riassumere: se devo programmare in Java, programmo in Java.
Non mi vedrai scrivere Java in Python.


Potrebbe essere che l'approccio di ZCA non mi piace ?

Perchè  ?


Perche' non sento il bisogno di interfacce esplicite.



Ti diro' di piu', da quello che vedo, e' qualcosa che gioca molto  
male con
il resto delle librerie che uso (che invece mi piacciono e mi  
servono).
Di fatto l'unico pezzo di zca che ho usato e' zope.interface. E no,  
non mi

piace.

Perché ?


Perche' risolve un problema che non ho. Ergo diventa automaticamente  
sovraingegnerizzazione.

Quando avro' quel problema, prendero' in considerazione zca.

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] "Go or Unladen Swallow? " Cosa ne pensate ?

2009-11-13 Per discussione luigi scarso
2009/11/14 Enrico Franchi :
> OK,  qual'e la tua osservazione in merito ad XML
>
> Che in generale e' un overkill.
Forse sgml.
> Come formato human readable fa un po'
> schifo,
(ok ,io avevo detto gran schifezza)
Mah
Nel senso che certi documenti docbook sono leggibilissimi,
certi documenti  svg sono illegibili nella loro interezza, ma in certe
parti sono chiari
certi documenti  UBL o pdx .. dopo un po ci si abitua .
Però non si punta molto su questo aspetto, perlomeno nel mio ambiente.

> come formato di macchina in generale ci sono alternative piu' compatte ed
> efficienti adatte per la specifica soluzione.
(ok mezzo fallimento, io avevo detto fallimento)
E' chiaro che xml non è la soluzione a tutti i problemi
e forse c'e' stato un periodo in cui tutto doveva diventare xml,
chiaramente un eccesso .
Ad esempio MARS di adobe non è particolamente attraente.

A me piace per il fatto di "xml ben formato -- obbligatorio"
e
"xml valido  -- facoltativo"

Mi ha sempre facilitato nell'individuazione deìi errori nei dati del cliente,
Si è sempre incastrato bene con python+lxml,
ma anche con xsltproc e xmllint.

Ecco, forse html non è proprio venuto bene.


Per il resto:
forse ti è sfuggito il fatto che per me questo thread è chiuso.
Io concordo con
http://www.python.org/dev/peps/pep-3003/

Tutto questo thread è una specie di finto flame war -- in certi
momenti molto realistico.

E' ovvio che uno è responsabile delle proprie affermazioni,
ma questo succede sempre, siamo persone adulte.


-- 
luigi
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB

2009-11-13 Per discussione luigi scarso
2009/11/13 Lawrence Oluyede :
> Boh io non ho nulla contro Go o contro XML. Mi sai che ne stai facendo
> un problema per
> trascinare la discussione che mi sembra più che morta.
L'argomento era ben preciso.
Hai inserito una tua forte considerazione  -- off topic ma
assolutamente interessante.
Quando ti ho chiesto delucidazioni in merito, non ho avuto delle
risposte convincenti.
Alla fine è risultata una "sparata", per tua ammissione.
Un po' eccessiva ?


-- 
luigi
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB

2009-11-13 Per discussione Lawrence Oluyede
2009/11/14 luigi scarso :
> L'argomento era ben preciso.
> Hai inserito una tua forte considerazione  -- off topic ma
> assolutamente interessante.
> Quando ti ho chiesto delucidazioni in merito, non ho avuto delle
> risposte convincenti.
> Alla fine è risultata una "sparata", per tua ammissione.
> Un po' eccessiva ?

Può darsi ma è la sensazione che quel tool mi ha fatto 2 anni fa in
quelle circostanze.
Se vuoi sottolineare l'off topic permettimi di dire che lo siamo da un bel po'

-- 
Lawrence Oluyede
[eng] http://oluyede.org - http://twitter.com/lawrenceoluyede
[ita] http://neropercaso.it - http://twitter.com/rhymes
[flickr] http://www.flickr.com/photos/rhymes
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] CouchDB

2009-11-13 Per discussione luigi scarso
2009/11/14 Lawrence Oluyede :

> Può darsi ma è la sensazione che quel tool mi ha fatto 2 anni fa in
> quelle circostanze.
> Se vuoi sottolineare l'off topic permettimi di dire che lo siamo da un bel po'

E' il contrario, forse non mi sono spiegato bene.

Dato che siamo sulla ml di python, quello che scrivi in questo momento
in un thread
*mi interessa* per principio,
indipendentemente da chi sei,
da cosa hai fatto, stai  facendo e farai.

La questione off-topic o meno è per me relativa:
è evidente che  altre persone che usano o useranno la ml vorrebbero
trovare un thread coerente ed informativo, quindi
io cerco di stare nell'argomento e di non farmi trascinare
fuori argomento, idem tu, idem tizio, caio  etc.
La regola (nel 2009) è cosi elementare e potente che  è quasi autoevidente:
anzi (nel 2009) è "presuntuoso" che uno dei partecipanti dica "off-topic" .

Per quanto mi riguarda, poi,
nel corso degli anni ho deciso
che niente è off-topic,
di stare in argomento,
di scrivere lo stretto necessario  -- se necessario !
di postare link utili -- e non è facile ..
di evitare "sprechi" di parole -- bisogna stare attenti a quello che
si dice e come: si parla col mondo intero, spesso in una lingua non
nativa,
meglio non fare troppo assunzioni in merito ad umorismo, religione,
orientamenti politici, sesso, razza etc. Sono argomenti esplosivi, nel
senso tragico del termine.

Inoltre se, come nel tuo caso,
fai una affermazioe "pesante"
la questione topic o meno diventa  irrelevante -- ovvero: parliamone
ora , spiegaci adesso questa cosa.
Ed è questo il significato di
>> Hai inserito una tua forte considerazione  -- off topic ma
>> assolutamente interessante.

Ora mi pare chiaro che una tua "sensazione" negativa
di 2 anni fa su un tool oggettivamente utilizzato da parecchi utenti
è troppo poco per essere condivisa *oggi* con altri della ml
senza essere più che motivata.

Forse non ti rendi conto, ma
>Ci ho buttato via 3 mesi della mia vita due anni fa su quel coso. È la
>cosa più tremenda che Oracle e BDB
>potessero partorire. Lascia perdere :-)

estendi in modo arbitrario le tue considerazioni negative ad una intera
azienda, la potrebbe aver qualcosa
da ridire almeno in termini di rispettabilità di immagine,
e  potenzialmente coinvolgi questa ml pubblica in una questione tua
del tutto privata.


E questo credo chiarisca  anche quanto sotto scritto da me in precedenza
>E... si, credo sia anche una questione generale di linguaggio di questa ml
>-- inaspettata, visti  i profili dei partecipanti.

-- 
luigi
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python