You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Armin Waibel <ar...@apache.org> on 2005/04/14 13:09:57 UTC
[OJB 1.x] Separation of PB-api from the kernel
Hi all,
For 1.x I suggest to completely separate the PB-api from the kernel. So
the PB-api will be an API like ODMG, JDO,... a kind of top-level api.
Further I want to avoid that OJB.java will became a conglomeration of
user and internal used methods. This class should be as simple as
possible, because it will be the first class of OJB a newbie will use.
Currently the first separation in PB-api is made by the
PersistenceBrokerInternal interface, but I recommend to do a real
separation by declaring PBF and PB as the "PB-api" and introducing in
start class OJB.java access methods for each api:
OJB ojb = new OJB();
Implementation odmg = ojb.getOdmg();
PersistenceManagerFactory pmf = ojb.getJdo();
PersistenceBrokerFactory pbf = ojb.getPBF();
OJB.java itself have access to the kernel PB pool (maybe OJB manage the
pool itself) and can be used by all API's. The current PBF class with
static methods should be changed to an interface, then the PB-api is
represented by the PB and PBF interfaces.
The top-level api will have kernel access via OJB.java. I suggest to
make a clear separation of user-OJB.java methods and methods only used
by the top-level api. Don't know what's the best strategy to do that.
Maybe if we introduce a interface OJBInternal (or something like that)
with access method to the kernel api, e.g. getBroker(PCKey key), ...
Then we can separate the common OJB methods from the methods used by the
top-level api's and the OJB.java user-methods are convenience methods to
OJBInternal:
class OJB
{
private OJBInternal internal = new OJBInternalImpl();
public PBF getPBF()
{
return new PBF(this);
}
...
// convenience method for user
public PC getPC()
{
internal.getPC();
}
...
// access for top-level api and advanced user
public getOJBInternal()
{
return internal;
}
}
// could be an inner class of OJB, should be pluggable
// to allow different implementations/extensions
class OJBInternalImpl implements OJBInternal
{
...
}
//
interface OJBInternal
{
// PB access for top-level api, e.g. will
// be used by PBF of PB-api
public PBInternal getBroker(PBKey key);
...
}
Then the top-level api using the PBInternal (PBI) instances in the same
way as jdbc-connection instances and the PB-api is a thin layer above
the OJB kernel.
The PB-api separation allows to extend the PB-api with additional
features or to replace it with a more sophisticated layer with
UnitOfWork/dirty detection stuff.
Any other suggestions or comments?
regards,
Armin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [OJB 1.x] Separation of PB-api from the kernel
Posted by Martin Kalén <mk...@apache.org>.
Armin Waibel wrote:
> For 1.x I suggest to completely separate the PB-api from the kernel. So
> the PB-api will be an API like ODMG, JDO,... a kind of top-level api.
> Further I want to avoid that OJB.java will became a conglomeration of
> user and internal used methods. This class should be as simple as
> possible, because it will be the first class of OJB a newbie will use.
<snip/>
> Then the top-level api using the PBInternal (PBI) instances in the same
> way as jdbc-connection instances and the PB-api is a thin layer above
> the OJB kernel.
> The PB-api separation allows to extend the PB-api with additional
> features or to replace it with a more sophisticated layer with
> UnitOfWork/dirty detection stuff.
>
> Any other suggestions or comments?
This looks great to me! I think this is the natural progression now that
so much of the old "PB-API" (=new kernel) is being reused from different
layers.
A clean separation of kernel functions from PB API makes, just as you say,
PB API qualify to the same league as ODMG et al. That might be less
confusing for new users, and is certainly cleaner in the code and promotes
the idea or re-using kernel functions from all layers (using PB API from
ODMG might seem a bit "twisted", but using a kernel from ODMG is natural).
It's less code to maintain and avoids that the same problems are being
solved in different ways in the different API:s.
On a similar note: what happened to Brian's Grafolia? Was that not
also a way of keeping object graph "excercises" centralized in code?
(Did not dig deep enought at the time to really know.)
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [OJB 1.x] Separation of PB-api from the kernel
Posted by Armin Waibel <ar...@apache.org>.
Jakob Braeuchi wrote:
> hi armin,
>
> i agree, we need to keep the kernel as small as possible (do you remeber
> my posts about pb getting bigger and bigger ?)
I believe we can found such posts 2 years ago ;-)
But I think while refactoring for 1.x we can separate some more components.
> i always considered the
> pb-api as the kernel, but actually i like the idea of pb-api as just
> another api. imo but we should use a proper naming for the kernel then,
> is pb-internal really correct ?
>
> to me the OJB.java looks like a big 'context' object holding all kind of
> configuration settings, but nothing else.
>
For me the PB-api is a subset view of the OJB-kernel. The kernel is the
"real O/R mapping layer". PersistenceBrokerInternal (PBI) represents the
kernel "O/R pipe" and PersistenceBroker is a subset of that functionality.
What will be a proper naming for the OJB-kernel and PBI?
I think 'OJB kernel api' is sufficient, because this term will only be
used by developer and PBI is a part of the kernel api.
I'm not satisfied with the PBI class naming, but I don't found a more
characteristical name (OJBBroker, KernelBroker, KernelConnection,
OJBConnection, ...).
regards,
Armin
> jakob
>
> Armin Waibel schrieb:
>
>> Hi all,
>>
>> For 1.x I suggest to completely separate the PB-api from the kernel.
>> So the PB-api will be an API like ODMG, JDO,... a kind of top-level api.
>> Further I want to avoid that OJB.java will became a conglomeration of
>> user and internal used methods. This class should be as simple as
>> possible, because it will be the first class of OJB a newbie will use.
>>
>> Currently the first separation in PB-api is made by the
>> PersistenceBrokerInternal interface, but I recommend to do a real
>> separation by declaring PBF and PB as the "PB-api" and introducing in
>> start class OJB.java access methods for each api:
>>
>> OJB ojb = new OJB();
>> Implementation odmg = ojb.getOdmg();
>> PersistenceManagerFactory pmf = ojb.getJdo();
>> PersistenceBrokerFactory pbf = ojb.getPBF();
>>
>> OJB.java itself have access to the kernel PB pool (maybe OJB manage
>> the pool itself) and can be used by all API's. The current PBF class
>> with static methods should be changed to an interface, then the PB-api
>> is represented by the PB and PBF interfaces.
>>
>> The top-level api will have kernel access via OJB.java. I suggest to
>> make a clear separation of user-OJB.java methods and methods only used
>> by the top-level api. Don't know what's the best strategy to do that.
>>
>> Maybe if we introduce a interface OJBInternal (or something like that)
>> with access method to the kernel api, e.g. getBroker(PCKey key), ...
>> Then we can separate the common OJB methods from the methods used by
>> the top-level api's and the OJB.java user-methods are convenience
>> methods to OJBInternal:
>>
>> class OJB
>> {
>> private OJBInternal internal = new OJBInternalImpl();
>>
>> public PBF getPBF()
>> {
>> return new PBF(this);
>> }
>> ...
>>
>> // convenience method for user
>> public PC getPC()
>> {
>> internal.getPC();
>> }
>> ...
>>
>> // access for top-level api and advanced user
>> public getOJBInternal()
>> {
>> return internal;
>> }
>> }
>>
>> // could be an inner class of OJB, should be pluggable
>> // to allow different implementations/extensions
>> class OJBInternalImpl implements OJBInternal
>> {
>> ...
>> }
>>
>> //
>> interface OJBInternal
>> {
>> // PB access for top-level api, e.g. will
>> // be used by PBF of PB-api
>> public PBInternal getBroker(PBKey key);
>> ...
>> }
>>
>> Then the top-level api using the PBInternal (PBI) instances in the
>> same way as jdbc-connection instances and the PB-api is a thin layer
>> above the OJB kernel.
>> The PB-api separation allows to extend the PB-api with additional
>> features or to replace it with a more sophisticated layer with
>> UnitOfWork/dirty detection stuff.
>>
>> Any other suggestions or comments?
>>
>> regards,
>> Armin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [OJB 1.x] Separation of PB-api from the kernel
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi armin,
i agree, we need to keep the kernel as small as possible (do you remeber
my posts about pb getting bigger and bigger ?) i always considered the
pb-api as the kernel, but actually i like the idea of pb-api as just
another api. imo but we should use a proper naming for the kernel then,
is pb-internal really correct ?
to me the OJB.java looks like a big 'context' object holding all kind of
configuration settings, but nothing else.
jakob
Armin Waibel schrieb:
> Hi all,
>
> For 1.x I suggest to completely separate the PB-api from the kernel. So
> the PB-api will be an API like ODMG, JDO,... a kind of top-level api.
> Further I want to avoid that OJB.java will became a conglomeration of
> user and internal used methods. This class should be as simple as
> possible, because it will be the first class of OJB a newbie will use.
>
> Currently the first separation in PB-api is made by the
> PersistenceBrokerInternal interface, but I recommend to do a real
> separation by declaring PBF and PB as the "PB-api" and introducing in
> start class OJB.java access methods for each api:
>
> OJB ojb = new OJB();
> Implementation odmg = ojb.getOdmg();
> PersistenceManagerFactory pmf = ojb.getJdo();
> PersistenceBrokerFactory pbf = ojb.getPBF();
>
> OJB.java itself have access to the kernel PB pool (maybe OJB manage the
> pool itself) and can be used by all API's. The current PBF class with
> static methods should be changed to an interface, then the PB-api is
> represented by the PB and PBF interfaces.
>
> The top-level api will have kernel access via OJB.java. I suggest to
> make a clear separation of user-OJB.java methods and methods only used
> by the top-level api. Don't know what's the best strategy to do that.
>
> Maybe if we introduce a interface OJBInternal (or something like that)
> with access method to the kernel api, e.g. getBroker(PCKey key), ...
> Then we can separate the common OJB methods from the methods used by the
> top-level api's and the OJB.java user-methods are convenience methods to
> OJBInternal:
>
> class OJB
> {
> private OJBInternal internal = new OJBInternalImpl();
>
> public PBF getPBF()
> {
> return new PBF(this);
> }
> ...
>
> // convenience method for user
> public PC getPC()
> {
> internal.getPC();
> }
> ...
>
> // access for top-level api and advanced user
> public getOJBInternal()
> {
> return internal;
> }
> }
>
> // could be an inner class of OJB, should be pluggable
> // to allow different implementations/extensions
> class OJBInternalImpl implements OJBInternal
> {
> ...
> }
>
> //
> interface OJBInternal
> {
> // PB access for top-level api, e.g. will
> // be used by PBF of PB-api
> public PBInternal getBroker(PBKey key);
> ...
> }
>
> Then the top-level api using the PBInternal (PBI) instances in the same
> way as jdbc-connection instances and the PB-api is a thin layer above
> the OJB kernel.
> The PB-api separation allows to extend the PB-api with additional
> features or to replace it with a more sophisticated layer with
> UnitOfWork/dirty detection stuff.
>
> Any other suggestions or comments?
>
> regards,
> Armin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [OJB 1.x] Separation of PB-api from the kernel
Posted by Brian McCallister <br...@chariotsolutions.com>.
It's chugging along. Code is in apache svn right now. Focus is on the
javax.jdo namespace and TCK right now.
-Brian
On Apr 14, 2005, at 2:00 PM, Thomas Dudziak wrote:
>> As long as we support the canonical PMF mechanism as well (if/when we
>> support JDO as more than a toy =)
>
> I hope that's a 'when' ? Any news on the Apache JDO project ?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [OJB 1.x] Separation of PB-api from the kernel
Posted by Thomas Dudziak <to...@gmail.com>.
> As long as we support the canonical PMF mechanism as well (if/when we
> support JDO as more than a toy =)
I hope that's a 'when' ? Any news on the Apache JDO project ?
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [OJB 1.x] Separation of PB-api from the kernel
Posted by Armin Waibel <ar...@apache.org>.
Brian McCallister wrote:
>
> On Apr 14, 2005, at 7:09 AM, Armin Waibel wrote:
>
>> PersistenceManagerFactory pmf = ojb.getJdo();
>
>
> As long as we support the canonical PMF mechanism as well (if/when we
> support JDO as more than a toy =)
>
It was only an example not a real suggestion, I don't want to despise
JDOHelper ;-)
Armin
> -Brian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [OJB 1.x] Separation of PB-api from the kernel
Posted by Brian McCallister <br...@chariotsolutions.com>.
On Apr 14, 2005, at 7:09 AM, Armin Waibel wrote:
> PersistenceManagerFactory pmf = ojb.getJdo();
As long as we support the canonical PMF mechanism as well (if/when we
support JDO as more than a toy =)
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org