 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Bob Dawson
Guest
|
 Posted: Thu Oct 23, 2003 2:18 pm Post subject: Object Persistence Session at BorCon |
 |
|
Joanna Carter, Jim Cooper, Wayne Niddery, and I have submitted a "Birds of a
Feather" panel session proposal for the upcoming BorCon. I'll post an
advisory here if/when we get a time-slot confirmed.
In the meantime--
If any other experienced OPF writers are planning to be at BorCon, please
let us know. Be a shame to have other forum regulars go
unrecognized/unacknowledged.
Those that are starting out or just interested, any specific questions you
want us to be thinking about for the next week?
bobD
|
|
| Back to top |
|
 |
Eric Hill
Guest
|
| Posted: Thu Oct 23, 2003 6:10 pm Post subject: Re: Object Persistence Session at BorCon |
|
|
| Quote: | Those that are starting out or just interested, any specific questions
you
want us to be thinking about for the next week?
|
I'm sorry I'm going to miss this one :)
Some random thoughts...
Most OOPF's make a traditional RDBMS person cringe with the auto-generated
schema. I would like to see some ideas about how to decouple the database
from the OOPF without breaking functionality. Queries of the OPF system
almost always take one of two forms; Either load every object to the client
and enumerate the objects with code, or use some language like OCL (Bold)
or a custom one (SeleQt) that builds a SQL statement to be executed against
the underlying engine. OCL is probably the best "generic" engine for this
task, but I've yet to see an OPF that takes /full/ advantage of the
underlying database.
For example, specialized indexing types (bitmap, full text, etc.) can
drastically speed queries along, but with generated SQL, you simply cannot
use those functions easily. The OPF's shouldn't require the application
developer to decide what kind of index is needed, but the database
developer would most definitely want the extra features.
Here are my questions:
Is OCL good enough to be able to produce optimized SQL? Could a better
abstraction between the OPF and the RDBMS allow for more flexible OCL->SQL
translations?
How would [you] go about building an OPF that can successfully decouple the
OPF from the RDBMS while retaining RDBMS-specific features, such as custom
indexes or stored procedures?
{$INCLUDE $0.02} Eric
|
|
| Back to top |
|
|
Steve-O
Guest
|
| Posted: Thu Oct 23, 2003 6:11 pm Post subject: Re: Object Persistence Session at BorCon |
|
|
"Bob Dawson" <bdawson (AT) idtdna (DOT) com> wrote
| Quote: | Joanna Carter, Jim Cooper, Wayne Niddery, and I have submitted a "Birds of
a
Feather" panel session proposal for the upcoming BorCon. I'll post an
advisory here if/when we get a time-slot confirmed.
|
Bob,
I would love to attend your session but I could not scrounge up the bucks
this year to make it to BorCon.
Will the notes of this session be made available for the general public to
download?
Thanks,
Steve-O
|
|
| Back to top |
|
|
Iman L Crawford
Guest
|
| Posted: Thu Oct 23, 2003 6:14 pm Post subject: Re: Object Persistence Session at BorCon |
|
|
"Eric Hill" <eric (AT) ijack (DOT) net> wrote in
news:3f981989$1 (AT) newsgroups (DOT) borland.com:
| Quote: | Most OOPF's make a traditional RDBMS person cringe with the
auto-generated schema.
|
My opinion is OOPF would work better with network or hierarchical db's.
Problem being everyone decided those sucked in comparison to relational
dbs.
--
Iman
|
|
| Back to top |
|
|
Eric Hill
Guest
|
| Posted: Thu Oct 23, 2003 6:36 pm Post subject: Re: Object Persistence Session at BorCon |
|
|
| Quote: | My opinion is OOPF would work better with network or hierarchical db's.
Problem being everyone decided those sucked in comparison to relational
dbs.
|
A stock RDBMS is very "easy" for an idiot to understand - tables, rows,
columns. It lets a user familiar with how the data is organized locate
patterns and relationships in the data that were not specifically built
into the original design. This gives a wide range of functionality not
available without programming on other systems - it's what makes RDBMS's so
powerful.
Hierarchical databases work pretty well for OPF back-ends, but don't lend
themselves well to queries to find undesigned patterns in the data. That's
partly why the HDBS went away in favor of the RDBMS.
I'm not familiar with "network" databases.
|
|
| Back to top |
|
|
Rob Schuff
Guest
|
| Posted: Thu Oct 23, 2003 7:04 pm Post subject: Re: Object Persistence Session at BorCon |
|
|
Hi bob and all,
From a beginner's (ok...a "studier" and not yet implementer)
perspective a couple come to mind:
1. What criteria to consider in deciding whether or not to buy/build an
OPF?
2. When trying to justify the expense in either effort or money to
embark on developing or purchasing an OPF it seems difficult to find
any kind of quantifiable data to make the case. What have been some
real-life quantifiable results?
3. Although this isn't necessarily an OPF issue directly, how about an
examination of how an OPF fits in a remoting architecture. And
possibly an example or two from some of the existing technologies (e.g.
RemObjects, .NET Remoting) might be good (not code, but high level
design examples, e.g. diagrams)
rob
Bob Dawson wrote:
| Quote: | Joanna Carter, Jim Cooper, Wayne Niddery, and I have submitted a
"Birds of a Feather" panel session proposal for the upcoming BorCon.
I'll post an advisory here if/when we get a time-slot confirmed.
In the meantime--
If any other experienced OPF writers are planning to be at BorCon,
please let us know. Be a shame to have other forum regulars go
unrecognized/unacknowledged.
Those that are starting out or just interested, any specific
questions you want us to be thinking about for the next week?
bobD
|
|
|
| Back to top |
|
|
Iman L Crawford
Guest
|
| Posted: Thu Oct 23, 2003 7:12 pm Post subject: Re: Object Persistence Session at BorCon |
|
|
"Eric Hill" <eric (AT) ijack (DOT) net> wrote in
news:3f981fc6$1 (AT) newsgroups (DOT) borland.com:
| Quote: | specifically built into the original design. This gives a wide range
of functionality not available without programming on other systems -
it's what makes RDBMS's so powerful.
|
Which is the primary reason I've been slow to adopt the "pure" oop approach
to application development.
| Quote: | I'm not familiar with "network" databases.
|
http://www.extropia.com/tutorials/sql/network_databases.html
--
Iman
|
|
| Back to top |
|
|
Bob Dawson
Guest
|
| Posted: Thu Oct 23, 2003 8:25 pm Post subject: Re: Object Persistence Session at BorCon |
|
|
"Eric Hill" wrote
| Quote: |
Most OOPF's make a traditional RDBMS person cringe with the
auto-generated schema. I would like to see some ideas about
how to decouple the database from the OOPF without breaking
functionality.
|
I agree that many/most OPFs assume a single-model approach whereby the
structure of the problem domain objects dictates the db structure, allowing
it to auto-generate queries (because the BO structures make the table
structures predictable) and even being taken to the level of object model
changes auto-generating db restructures and data migration. Essentially this
is the reverse of the concept of reading a database and autogenerating an
'application' based on it. Neither approach is actually necessary.
My own OPF recognizes the application/db relationship as contractual rather
than implicational--the db must supply required data, but there is no
systemic assumption as to the source structure, so the line
Cust := TCustomer.Create(12345);
may result in an SQL query of a single table, a join, or a storedproc--and
the framework is systemically blind to which might have occurred. This
degree of separation was required to accomodate deployment to an existing
system (OPF software does not enjoy complete dominion over legacy data), but
does involve additional maintenance (since there are really two models
cooperating, they have to be coordinated; neither design simply cascades to
the other side automatically. As my DBA says, "It's a matter of trade-offs."
In other words yes, I think I understand the concern, and yes, there are
ways to handle it.
| Quote: | How would [you] go about building an OPF that can successfully
decouple the OPF from the RDBMS while retaining RDBMS-specific
features, such as custom indexes or stored procedures?
|
My approach was to treat persistence as just another problem domain, and
model it with business objects whose state (and hence behaviour) is
table-driven, just like any other business object. I have (if memory serves)
about 3 bootstraps queries hard coded which tell the system how to load the
business objects that tell it how to CRUD all other objects.
bobD
|
|
| Back to top |
|
|
Bob Dawson
Guest
|
| Posted: Thu Oct 23, 2003 8:34 pm Post subject: Re: Object Persistence Session at BorCon |
|
|
"Steve-O" wrote
| Quote: | Will the notes of this session be made available for the general
public to download?
|
I don't anticipate posting notes to the web personally, but did make them
available for anyone who requested, either by email or by loading them to
borland.public.attachments. Probably do the same this year.
Joanna already has some very good stuff at her website,
www.carterconsulting.org.uk. Can be heavy going if you're not already
proficient at interface programming.
bobD
|
|
| Back to top |
|
|
Bob Dawson
Guest
|
| Posted: Thu Oct 23, 2003 8:52 pm Post subject: Re: Object Persistence Session at BorCon |
|
|
"Rob Schuff" wrote
| Quote: |
1. What criteria to consider in deciding whether or not to buy/build an
OPF?
|
Reuse and longevity. Writing generic persistence code is a considerable
investment, and the major rewards for that investment are only seen if the
results are going to be used in multiple applications or for a considerable
time (A well-layered, decoupled system is easier to maintain and adapt over
time than either a monolith or multiple, inconsistent code bases).
| Quote: | 2. When trying to justify the expense in either effort or money to
embark on developing or purchasing an OPF it seems difficult to find
any kind of quantifiable data to make the case. What have been some
real-life quantifiable results?
|
Not aware of any hard, PHB-presentable studies on the issue. Borland has
come case studies on Bold adoption I believe (and Bold is an OPF, among
other things).
| Quote: | 3. Although this isn't necessarily an OPF issue directly, how
about an examination of how an OPF fits in a remoting
architecture. And possibly an example or two from some of
the existing technologies (e.g. RemObjects, .NET Remoting)
might be good (not code, but high level design examples, e.g.
diagrams)
|
I'd punt on this one to one of the other panelists. My own work has been
deployed in a traditional fat-client C/S environment, so while it's 3-tier
in concept, I've never had to physically separate the GUI from the object
layer.
bobD
|
|
| Back to top |
|
|
Eric Hill
Guest
|
| Posted: Thu Oct 23, 2003 9:25 pm Post subject: Re: Object Persistence Session at BorCon |
|
|
| Quote: | My own OPF recognizes the application/db relationship as contractual
rather
than implicational--the db must supply required data, but there is no
systemic assumption as to the source structure, so the line
Cust := TCustomer.Create(12345);
may result in an SQL query of a single table, a join, or a
storedproc--and
the framework is systemically blind to which might have occurred. This
|
Agreed, but what happens when the application developer needs to execute a
query on behalf of the application user? An example is a search for an
open order for a customer. You may have the customer name, you may just
have the last name, maybe just the company name, or a phone number... How
do you build an OPF in such a way that this random smattering of data can
be translated into a properly optimized SQL (or other) query? That's
really the crux of my question.
| Quote: | My approach was to treat persistence as just another problem domain, and
model it with business objects whose state (and hence behaviour) is
table-driven, just like any other business object. I have (if memory
serves)
about 3 bootstraps queries hard coded which tell the system how to load
the
business objects that tell it how to CRUD all other objects.
|
Really? That sounds like a good idea - will you elaborate in your
presentation pretty please? :)
Eric
|
|
| Back to top |
|
|
Bob Dawson
Guest
|
| Posted: Thu Oct 23, 2003 10:03 pm Post subject: Re: Object Persistence Session at BorCon |
|
|
"Eric Hill" wrote
| Quote: | have the last name, maybe just the company name, or a phone
number... How do you build an OPF in such a way that this
random smattering of data can be translated into a properly
optimized SQL (or other) query? That's really the crux of my
question.
|
Again, modeled as a business object and data driven. IOW, if we're going to
allow ad-hoc queries of a business object, the BO class gets a secondary
object defined on it that holds information on what the maximum resultset
rows allowed is, and a collection of the fields can be queried, the
fully-qualified db field name and constraint conditions allowed on each,
etc.
Ad-hoc queries are really collection queries, so the selection clause of an
object selector is used, the where clause stripped off, and constraint
conditions (a new where clause) created and appended, guided by the above
described meta-data. The details of this are all handled back in the
persistence service layer. The application programmer can use the available
information from the service object directly or can present all the options
to the user to choose from via a generic frame we provide. Once fired, the
collection has a boolean property that the programmer can check telling
whether the MaxResultset was returned, and so indicating that the user needs
to further refine the query.
Defining the secondary object on the business object to be interrogated is
relatively simple, since it's essentially a BO insert operation; we have a
utility program to do it with.
At run time, the BO's being used by the persistence layer to maintain
persistence information have to be loaded, so that the first time a bisiness
object class is accessed there's some overhead while the OPF loads the info
on how to handle the class, but then the persistence layer caches those
internal 'service' objects for a certain period of time after the last
object of the exposed class is freed. As a result, the effective runtime
burden of the system is quite light.
| Quote: | Really? That sounds like a good idea - will you elaborate in your
presentation pretty please? 
|
Certainly willing to. Much to talk about, and so little time...
bobD
|
|
| Back to top |
|
|
Jim Cooper
Guest
|
| Posted: Fri Oct 24, 2003 10:20 am Post subject: Re: Object Persistence Session at BorCon |
|
|
| Quote: | Queries of the OPF system almost always take one of two forms;
Either load every object to the client and enumerate the objects
with code, or use some language like OCL (Bold) or a custom one
(SeleQt) that builds a SQL statement to be executed against
the underlying engine.
|
You can use hard-coded queries too. I find I often have to do that for
reporting, for instance.
Cheers,
Jim Cooper
____________________________________________
Jim Cooper [email]jcooper (AT) tabdee (DOT) ltd.uk[/email]
Tabdee Ltd http://www.tabdee.ltd.uk
TurboSync - Connecting Delphi with your Palm
____________________________________________
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
