--- Scott Tavares <[EMAIL PROTECTED]> wrote:
> ----- 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.
Thanks.
> > 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?
>
Yeah, sort of. Let's use the Employee example and,
say we want to have a proxy for it. My suggestion is
to provide a mapping that says "Employee" -> "Employee
Proxy". Then ou provide complete class map for
"Employee Proxy". Note that P.O. is the argument to
getClassMap() in the Persist Broker.
> >
> > 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.
>
Hope you're not mad about this.
Some days back we talked about a broker manager, and
you liked the idea. There is still a "hook" for the
turbine broker.
Here's my example code which use Marc Minch's code:
DbBrokerManager.getInstance().register(
brokerName,
"org.apache.turbine.opl.database.JavaExchangeBroker",
properties);
So, simply by writing in implementation of the broker
interface we can put in any stinking broker.
Actually, I'm glad somebodyelse had done all the work.
Would you like a copy of mine for Marc's stuff? I
didn't put it cvs, because that could break the build,
and I don't know about the legal issues.
> 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;}
>
Oops. I've been in hurry.
> 2. the default size should be set to one.
>
Let's take a poll. I know Scott suggests this, but
it's so not A.I. So, you have to know how many
records you want. There are tons of places that we
require some arbitrary number greater than 1.
IMHO, this really should be a system configuration.
> 3. the defaultSize() method, according to the
> design, should be static (see the bottom of page 12
> for the reason why).
>
I'll read it.
> 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?
>
Not really finished. I will add some stubs. It will
do multi-record just give me 2 days. You're right
about the next. I have to think about this...
> 5. instead of using RecordSet use Village's
> TableDataSet.
>
Yeah, maybe we should this. I would like village
better if it was more separated like this opl stuff.
I bet jon would rather have users switch to opl then
to spend time to on it. -:) Now how do guys do those
smily faces.
> 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's paper hints at this approach. I sent him a
mail as to why but he didn't answer. This doesn't
make sense to me. It's more headache to deal with it
in the same list, much easier in a different list. I
can't see any advantage to the single list. Please
look at what's in cvs for the udaMap.
I have some of the implementation done for the
associations, but it needs more work. I can mail you
some of the code if you'ld like.
-- george
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://messenger.yahoo.com
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
