----- Original Message -----
From: george stewart <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 28, 1999 3:37 PM
Subject: opl
> Scott,
>
> I will move the Cursor class. I just haven't had time
> to find the instructions in the cvs book. All my
> spare time has gone to the code.
>
i'll take care of this.
> My hope
> is that we can also implement proxies without
> ProxyAttribute.
>
At first, i was going to disagree with this but, now that i looked closer at
this there is really no need for ProxyAttributeMap if AttributeMap has a
isProxy() method then you can just fetch the Attributes that return true
when building proxy objects. is this your thinking on this?
>
> If someone is looking for something to contribute,
> they could submit an implementation of DbBroker which
> uses the one in turbine. Can this be done?
>
why did you remove this code:
]
]dbBroker = DBBroker.getInstance();
]
]// Get a connection to the database.
]try{
] connection = dbBroker.getConnection();
]}catch(Exception e){
] e.printStackTrace();
]}
]
]// Get a highValue for the OID.
]highValue = getHighValue();
]
from the PersistentBroker constructor?? this was the hook to Turbine's DBBroker and
DBConnection...
Doing it this way means that there is no need for the /database/DbBrokerManager,
/database/DbBroker, or /database/DbConnection classes.
On the Cursor class:
1. don't like the use of what i call "friendly" method declaration so this:
int defaultSize() {return 50;}
void setSize(int size) {this.size = size;}
should be
public int defaultSize() {return 50;}
public void setSize(int size) {this.size = size;}
2. the default size should be set to one.
3. the defaultSize() method, according to the design, should be static (see the bottom
of page 12 for the reason why).
4. from what is in the Cursor.java file, it appears to be incomplete. Missing the
nextProxies(), nextRows(), previousObjects(),
previousRows(), previousProxies() which is fine but i note this because the
of the way that nextObjects() is implemented. it is either not complete or
you may be overlooking the need to support more that one PO being fetched. I
think that putting the PersistentObject as an argument to the nextObjects()
and how it clears all it attributes then retrieves them (very cool) is goog,
but how would ever support a multi-object fetch? Lastly, from what i can see
in the code, _what_ PO to fetch is not being taken into account. i see that
you have a next() public method that moves the record pointer down one in
the RecordSet but the nextObjects() method completely disregards this vital
piece of information. am i missing something here?
5. instead of using RecordSet use Village's TableDataSet.
On the UniDirectionalAssociationMap:
i know this topic has come up before but do you have a plan of how you
intend to complete this class? I took a closer look at the design and AFA i
can tell the UniDirectionalAssociationMap should seem to be just another
ColumnMap to a AttributeMap that holds it except that it holds a collection
of other dependent PO's. (more recursion). with this in mind do you think
that UniDirectionalAssociationMap and ColumnMap should have a common
ancestor?
-scott-
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
