On Sep 15, 2005, at 9:46 AM, Michiel Meeuwissen wrote:
Sorry (for pierre) this vote is already a little messy but i agree
with Michiel on these issues and will follow his
vote on these topics.
I think Nico is right in that we want mmbase to be more and more
'just a j2ee' product but also agree
that we would like to be able to keep using mmbase in applications
(point kees and others made) and that
we can atleast fall back to the imho easy configuration method we
have now in jdbc.xml. Ill also -1 any option
that doesn't allow us to keep hsql as a starting point (i always tell
people start with that first, then switch databases once
up and running, it also means its very easy to test/compare between
atleast 2 databases for everybody).
Daniel.
2005/9/13, Nico Klasens <[EMAIL PROTECTED]>:
[ X] -1 (NO)
I too feel that everywhere MMBase, besides in one DataSource
implementation, JDBC should not explicitel be used. So I think agree
on half of the proposed removals or so.
But I won't like the complete disappearance of MultiPool and JDBC
because
- It is simply configurable by a database URL. More simple than that
is hardly possible, which gives several advantages
- We can ship a working mmbase with an hsql url.
- You can easily try out another app-server you are not familiar
with.
- Running stand-alone remains an option, also for junit tests
- It is possible to get the database name, because that is in the
connection url...
This is currently not used, but I would like it as a fall back for
hsql, because
its connection.getCatalog() simply always returns null (few days
back I asked quest about this on hsql's dev-list, but no
response yet :-()
I think it is a bit important to know the actual database name, e.g.
for blob dirs.
Is there a way to do this using only DataSource? Is 'getCalalog()'
the right way, and is this a bug of hsql?
Furthermore is the MultiPool code of course a distaster but I think
that perhaps now it is reasonably good and at least longly tested, and
it remains to be seen if implementations offered by app-servers are as
good.
But of course I'm all +1 for cleaning up al other mess. I'll change to
+0 with the amendements of Pierre, and to +1 if jdbc.xml with its
basic classes (JDBC, MultiPool and one or two others) simply remain
forever, though of course cleaned, or - of course - if one can
convince me that my points are invalid or irrelevant.
Michiel
--
mihxil' http://mihxil.komputilo.org/
nl_NL eo_XX en_US
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
