----- Original Message -----
From: george stewart <[EMAIL PROTECTED]>
To: Turbine <[EMAIL PROTECTED]>
Sent: Tuesday, December 28, 1999 10:48 PM
Subject: Re: opl
> > > 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.
>
so each PO will have two ClassMap objects to maintain, one for Proxy and one
for the full PO? This sounds like a good idea but i'm still on the fence.
i'm a little concerned that this will make the complicated task of
maintaining the ClassMap(s) just that more difficult. do you an objection of
just using the isProxy() method to include/exclude attributs from a Proxy?
> > why did you remove this code:
> >
> > ]
> > ]dbBroker = DBBroker.getInstance();
> > ]
> > ]// Get a connection to the database.
> >
> > ] 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.
>
1. no, i'm not mad... (a little angry maybe... just kidding)
2. i do like the idea of being able to swap out Brokers.
3. can't use Marc's stuff because of reasons that jon* has already stated.
4. couldn't we create a Turbine like service and make Turbine's DBBroker the
default?
> > On the Cursor class:
> >
> > 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.
ok lets make it a system configuration, but i still think it should be set
to one as its default ; )
>
> > 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.
>
do you agree?
> > 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...
>
i'll keep an eye out for it.
> > 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.
on the fence about this also, either way has their pros and cons. as for
simplicity, why deal with two list when you can have one and just use an
instanceof to filter the objects? in terms of reading the code, it would be
easier to do using two lists... (this is not very helpful is it ?) do what
you think is best.
-scott-
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
