[Opensource] Re: Re: DBObjects limitations

[Peter A. Pilgrim]

inadareishvili at worldbank.org wrote:
> Dear Peter,
> 
> Thanks a lot for taking time to reply.
> 
> 1) I would assume "problem" with implementing UPPER, LOWER, UNIQUE, DECODE etc.
> is that it would "ruin" the persistence's generosity (DB-independance), as
> different RDBMS name these functions differently and not all even have all of
> them? Even so, I guess a lot of developers would subscribe to the importance of
> these keywords. If we leave out ligfht-weght, non-standard-conforming RDBMS like
> MySQL, most others should have the functions in one form or other? Do you know
> if anybody has tried to subclass DBobjects classes to add the functionality
> (passing DB name as an argument to allow db-dependant implementation or
> something)? Or maybe you would point-out some other method/technique that is
> more appropriate in DBObjects world and leads to effectively same results?
> 

If I understand you correctly. You want to filter data inside actual columns.

SELECT UPPER(LAST_NAME) FROM EMPLOYEES;

and also add new records, or update records using these filters.

INSERT INTO EMPLOYEE ( LAST_NAME, FIRST_NAMES )
VALUES ( UPPER('pIlGrIm'), LOWER('PeTeR A' ) )

The problem is that not everybody needs these filters. MySQL and PostgreSQL
have UPPER, LOWER. I have no idea what UNIQUE does? I know DECODE is an
Oracle specific notation function.

I have not heard any one on the list implementing field name filtering.
Also it complicates the information retrieval and storage? Are you
using the same filter to query and you might store?

I think you would have to modify DBField.java and DBObject.java
to add this functionality. Since the OR/M is used a wide codebase
we cant add extra code that impacts people who dont need
what I would call, "data field filtering"


> 2) Problem with cmplex WHERE conditions is that, DBobjects is kindof too
> unflexible (?), so when we need complex selects, the only way to do it, really
> seems to be putting the entire WHERE into method call like
> custList.setCustomWhereClause("CustomerType = \"AA"\ OR CustomerType = \"BA"\")
> but doing that kills the whole abstraction of persistence layer - if, later on,
> data-model changes will occure, those places, with setCustomWhereClause, will
> have to be patched manually - which may occur to be  lots of work.
>

How do you build this generically. In antifact all you are doing is
adding an extra wrapper to OR/M that ultimately writes SQL command string
to execute. One could write a functional object sort of API
that programmatically generating an SQL where clause

	WhereClause myWhere = new WhereClause(
		new OR(
			new Equals( "CustomerType", "AA" )
			new Equals( "CustomerType", "BA" ) ));
	System.out.println( myWhere )

	=> "( CustomerType = \"AA"\ OR CustomerType = \"BA"\" )"

In fact Jakarta has ECS project that generate well informed HTML and XML
from Java Objects.


> Reply from Paulo Dias seems to be answer to this issue, though. Again - assuming
> that all RDBMS, under question can recreate that complex views and support
> views.
> 
> Raw JDBC seems easy escape, that a developer would tend to use, untill software
> architect or QA guy notices it and comes down yelling and roaring :-)
> Seriously, concern with using straight JDBC are 1) permissioning (Expresso
> permissioning is tied to DBObjects, right?) 2) bad scalability 3) falling out of
> overall object-oriented picture.
> 
Expresso SecuredDBObject have security applied to them.
Bad scalability? What do you mean by that?
If you to keep on with OO architecture then see ECS (Element Construction Set
http://jakarta.apache.org/ecs for inspiration ).

> 3) Sorry, for complicating the question about "virtual tables". What I really
> meant is the problem of pagination. Indeed, MySQL has this nice LIMIT keyword,
> but as you know Oracle does not have that. What we usually use is complex INNER
> SELECT with rownum to achieve LIMIT's functionality in Oracle. But that is not
> doable in DBObjects any more. So, how would we handle pagination issues?
> 
> You said:
> 
>>I patched DBObject.java on this issue 18 months ago or so.
> 
> Could you, please, share the code. That would be very helpful

DBObject have had support for DISTINCT types since Expresso Framework 2.1

--////--

-- 
Peter Pilgrim
ServerSide Java Specialist

My on-line resume and for interview videos about myself, J2EE
Open Source, Struts and Expresso.
    ||
    \\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''