On Friday, Sep 26, 2003, at 10:26 Europe/Rome, Gianugo Rabellino wrote:


Antonio Gallardo wrote:
hi:
Please vote about this proposal:

Antonio,


there's no need to vote in order for you to add code into CVS. Just go ahead and commit. :-)

This said, this is not a vote but a few questions:

1. I still don't see why it shouldn't be part of the database block. I understand that dealing with databases directly (manual SQL) or through a persistence layer is somewhat different, but then again, with the _current_ blocks, I don't quite see the need for "balkanization" of database handling stuff;

2. in case such need exists, I'd rather see a "persistence" block with a set of different implementations (OJB being just one of those).

eheh, block polymorphism starts to be asked explicitly. this is good, the concepts are starting to percolate thru.


Antonio, you don't need a vote for creating a new block, just a proposal where people can submit suggestions on the best way to move forward (like gianugo is doing right now).

Gianugo, separation is not necessarely showing balkanization (it would be if the different communities started to act against one another, but this isn't the case) and block behaviors will generate a taxonomy, and taxonomies are notoriously hard to find because categorization is the first form of politics.

I would suggest to follow a KISS principle: start with the ojb block today and create a 'persistence block behavior' later.

Is this part of the database block? don't think so. the database block behavior is about accessing databases *explicitly* and *willingly* (because your data resides there). the persistence block behavior is about storing your data in a persistent way, the fact of using a database is simply an implementation detail (the concept of databases as we know them might not be there anymore, look at prevailer or all the new ram-only + disk log database architectures).

but again, database is not only RDBMSonDisk, and here the taxonomy fun begins ;-)

--
Stefano.



Reply via email to