Pierre van Rooden <[EMAIL PROTECTED]> wrote:
> Questions that do not follow this format are not concidered proper
> calls, as people may miss the intention of the message.
I did not (yet) intend to make it a proper call, only to collect opinions.
But well, ok..
CALL FOR:
Currently the NodeManager.getList function of the bridge works like this
NodeList list = nodeManager.getList(where, orderby, directions);
And if 'where' is wrong, e.g, contains non-existing fields, then list will
simply be an empty, which is rather confusing.
This is because the 'search' methods in MMObjectBuilder behave
correspondingly.
I would like to add functions to MMObjectBuilder which would let the
SQLException go, use those functions in the implementation of NodeManager
and then you get exceptions like this from it:
ava.sql.SQLException: Column not found: Unknown column 'pos' in 'order
clause'
at org.gjt.mm.mysql.MysqlIO.sendCommand(MysqlIO.java:498)
at org.gjt.mm.mysql.MysqlIO.sqlQueryDirect(MysqlIO.java:551)
at org.gjt.mm.mysql.MysqlIO.sqlQuery(MysqlIO.java:636)
at org.gjt.mm.mysql.Connection.execSQL(Connection.java:924)
at org.gjt.mm.mysql.Connection.execSQL(Connection.java:857)
at org.gjt.mm.mysql.Statement.executeQuery(Statement.java:169)
at org.gjt.mm.mysql.jdbc2.Statement.executeQuery(Statement.java:78)
at
org.mmbase.module.database.MultiStatement.executeQuery(MultiStatement.java:184)
at org.mmbase.module.core.MMObjectBuilder.getList(MMObjectBuilder.java:1101)
at org.mmbase.module.core.MMObjectBuilder.searchList(MMObjectBuilder.java:1357)
at
org.mmbase.bridge.implementation.BasicNodeManager.getList(BasicNodeManager.java:159)
Which is rather a lot more helpfull then an empty list (well, granted, the
exception appears in the log).
As you see the new functions in MMObjectBuilder are like searchVector but
will be called searchList (which besides throw SQLException also return List
rather then Vector).
The bridge-user (e.g. the taglib) can simply let the exception go (and it
will be display on the error page), or catch to do something reasonable (can
e.g. log it as an error if this really is wanted). At least you
have the choice then.
Some constraints checks are already done in the bridge implementation
'validConstraints' of BasicCloud, but it is obviousely not smart enough, and
I think it can just as well be left to the database itself...
I would like to apply this change, but it is not absolutely backwards
compatible, so I call for a vote. I can hardly imagine that there are
bridge-users who depend on the list being empty if it is fed with wrong
arguments, but one never knows..
LINKS:
none.
START OF CALL: 2002-09-25
END OF CALL: 2002-09-30
[_] +1 (YEA)
[_] +0 (ABSTAIN )
[_] -1 (NAY), because :
[_] VETO, because:
Michiel
--
Michiel Meeuwissen
Mediapark, C 107 tel. +31 (0)35 6772979
