If this information would be considered as advertising and therefore
could not be published, please send me an email. (Remove underscores
please)
Thanks a lot
Alex
I'm interested too. Post it to the group please.
Then that guy does not have a clue on he talks about.
Object-relational mapping is a great blunder. You should read real
experts and keep away from tricksters.
Regards
Alfredo
You do not think that tools that automatically bind a SQL result set to the
properties of an object are useful? That hide all the details of database
connections, opening and closing them, and expose a higher level API to the
programmer? When we are interacting with databases from applications
written with conventional programming languages, we are typically using a
database API supplied by a vendor. These API's have never been particularly
well designed from the point of view of the application programmer, and good
tools can vastly simply programming. People have been doing this from the
very beginning, in C, C++, Java, and on. It's easier with the newer
languages that support reflection.
Maybe your objection is to some feature of so called object-relational
binding tools? The fact that some of them require binding directly to
tables rather than to SQL result sets? The fact that some of them like
TopLink have ridiculous caching schemes within the app process? The fact
that some of them impose restrictions on the database schema, perhaps
requiring a one part numeric key on all tables? The fact that some always
seem to want to return arrays of values? There is nothing inherently OO
about any of this, and none of these features need be part of an
OO-relational tool.
Regards,
Daniel Parker
Well if YOU knew anything about real industrial strenght OO/R mappers then you
would know that many of them do provide full ad-hoc query capabilities and joins etc,
and thus allow ternary relationship resolution. I.e. they do not suffer from the
limitations that you are aluding to.
For the benefit of the OP the ones I know of are OJB, Hibernate, Toplink,
Cocobase - do a google on these.
Paul C.
> Well if YOU knew anything about real industrial strenght OO/R mappers
I know that they are based in an ill concept.
> then you
> would know that many of them do provide full ad-hoc query capabilities and joins etc,
> and thus allow ternary relationship resolution.
Irrelevant. You can not build anything solid with completely corrupt
foundations.
Languages like OQL are a complete mess and horribly complex, and they
are not more powerful than SQL.
Regards
Alfredo
> Hello,
> Martin Fowler strongly recomends using a third-party tool for the
> object-relational mapping, but doesn't provide any names.
> Could anybody suggest such a tool, please?
> We work with .NET.
for .NET persistence look e.g. at the following
some relevant groups and places
* usenet: microsoft.public.objectspaces
* http://groups.msn.com/DotNetPersistence
* http://dotnetguru.org/ section on persistence
* full blown persistence products: just some examples ...
* Pragmatier for VB.NET and C#
http://www.pragmatier.com
* FastObjects for C#
http://www.fastobjects.com/
* db4o
http://www.db4o.com
Hope that helps
Wolfgang
http://www.objectarchitects.de/
>"Alfredo Novoa" <alf...@ncs.es> wrote in message
>news:e4330f45.04031...@posting.google.com...
>> aizik_...@yahoo.com (Alex) wrote in message
>news:<8794af5f.04031...@posting.google.com>...
>> > Hello,
>> > Martin Fowler strongly recomends using a third-party tool for the
>> > object-relational mapping
>>
>> Then that guy does not have a clue on he talks about.
>> Object-relational mapping is a great blunder. You should read real
>> experts and keep away from tricksters.
>>
>You do not think that tools that automatically bind a SQL result set
to the
>properties of an object are useful?
I can bind visual controls (objects) to database tables without any
tool or using the tools provided by the IDE. But it does not have any
relationship with object-relational mapping.
> That hide all the details of database
>connections, opening and closing them, and expose a higher level API
to the
>programmer?
Higher level API than SQL?
Are you kidding?
With O-R mappers you hide a high level declarative interface (SQL)
behind a primitive procedural interface (3GL).
> When we are interacting with databases from applications
>written with conventional programming languages, we are typically
using a
>database API supplied by a vendor.
But the API is only a mechanism to submit SQL queries and to return
the results. It is not a very important issue.
> These API's have never been particularly
>well designed from the point of view of the application programmer,
and good
>tools can vastly simply programming.
And bad tools like O-R mappers make programming a lot more costly.
>Maybe your objection is to some feature of so called
object-relational
>binding tools?
No, object-relational mapping consist in the attempt to equate classes
and tables, which is a big blunder. Classes are the same as database
domains. Object-relational mapping is a fatally flawed concept.
Object Relational mapping tools also promote to manage data in the
applications instead of the DBMSs. It is a return to the stone age of
the Information Systems.
>The fact that some of them require binding directly to
>tables rather than to SQL result sets?
The fact that they require to manage the data in the application
manually transversing pointer labyrinths using a low level procedural
language.
> The fact that some of them like
>TopLink have ridiculous caching schemes within the app process?
It is a lot worse than that.
> The fact
>that some of them impose restrictions on the database schema, perhaps
>requiring a one part numeric key on all tables? The fact that some
always
>seem to want to return arrays of values? There is nothing inherently
OO
>about any of this, and none of these features need be part of an
>OO-relational tool.
The biggest problems are inherent to the ill approach.
The irresponsible ignorant tricksters who promote such crap are
causing a big harm to the industry.
OO is not for data management.
Regards
Alfredo
Regards,
Daniel Parker
> I can bind visual controls (objects) to database tables without any
> tool or using the tools provided by the IDE. But it does not have any
> relationship with object-relational mapping.
>
Uh, huh, and what if you were writing code as a creator rather than a user
of visual controls? Mapping SQL result sets to instance variables is a big
part of what object-relational mapping is about.
> > That hide all the details of database
> >connections, opening and closing them, and expose a higher level API
> to the
> >programmer?
>
> Higher level API than SQL? Are you kidding?
>
What does SQL have to do with opening and closing database connections?
Have you never seen code like this before?
Connection connection = DriverManager.getConnection(
databaseUrl, user, password);
connection.setAutoCommit(false);
Statement stat = connection.createStatement();
ResultSet resultSet = stat.executeQuery(sqlQuery);
while (resultSet.next()) {
// Do something;
}
resultSet.close();
connection.close();
Now, if we added nested connections and transactions and error handling and
binding the result values to instance variables, things would start to
become interesting. There's nothing wrong with SQL, but most of the lines
of code here are concerned with other things, and those are the things that
should be the primary focus of OO-Relational binding.
> With O-R mappers you hide a high level declarative interface (SQL)
> behind a primitive procedural interface (3GL).
>
Does anything I've written above suggest that's what I do?
> > When we are interacting with databases from applications
> >written with conventional programming languages, we are typically
> using a
> >database API supplied by a vendor.
>
> But the API is only a mechanism to submit SQL queries and to return
> the results. It is not a very important issue.
>
In a data processing application written in C, C++, Java, etc., the number
of lines of code to do these things could be very large. And it's all
stupid code. That's what object-relational mapping abstractions are, or
should be, about. Personally, I don't want to write a single line of code
to put a date variable from a SQL result set into a C# DateTime property,
repeated many times over for all of the other variables. And I don't have
to. A SQL results set comes across the wire with a complete set of metdata
describing the data, and a Java or C# class also has a complete set of
metadata describing its properties. That's what object-relational mapping
tools are supposed to do, they make use of that information, greatly
simplifying programming.
> >Maybe your objection is to some feature of so called
> object-relational
> >binding tools?
>
> No, object-relational mapping consist in the attempt to equate classes
> and tables, which is a big blunder. Classes are the same as database
> domains. Object-relational mapping is a fatally flawed concept.
>
Object-relational mapping is about mapping the results of SQL queries to the
properties of in-memory objects. I agree with you that mapping objects
one-to-one with individual database tables is a bad idea. I agree that
there have been products that required this, and I agree that they were bad
products. How is it that you came to believe that that was all that
object-relational mapping was about?
> Object Relational mapping tools also promote to manage data in the
> applications instead of the DBMSs. It is a return to the stone age of
> the Information Systems.
Look, we need to bring data into in-memory objects so we can process it, we
have business requirements, we need to process payrolls, generate extract
files, calculate how much we have to pay our customers, etc. Do I have to
tell my mutual fund clients that they can't send out cheques to their sales
reps because doing so would be a return to the stone age?
Regards,
Daniel Parker
> >>You do not think that tools that automatically bind a SQL result set
> >>to the properties of an object are useful?
>
> > I can bind visual controls (objects) to database tables without any
> > tool or using the tools provided by the IDE. But it does not have any
> > relationship with object-relational mapping.
> >
> Uh, huh, and what if you were writing code as a creator rather than a user
> of visual controls?
Then it has even less relationship with object-relational mapping.
To create a new datagrid object for the .NET framework (for example),
does not have any relationship with the called O-R mapping.
> Mapping SQL result sets to instance variables is a big
> part of what object-relational mapping is about.
Agreed, but what I say is that it is a completely wrong way to map SQL
results to application objects.
> What does SQL have to do with opening and closing database connections?
SQL is the interface with a SQL DBMS.
> Have you never seen code like this before?
>
> Connection connection = DriverManager.getConnection(
> databaseUrl, user, password);
> connection.setAutoCommit(false);
> Statement stat = connection.createStatement();
> ResultSet resultSet = stat.executeQuery(sqlQuery);
> while (resultSet.next()) {
> // Do something;
> }
> resultSet.close();
> connection.close();
It is trivial to abstract this stuff into components. Again there is
no relationship with O/R mapping. You can do that in Visual Basic,
Delphi, Power Builder, etc.
> Now, if we added nested connections and transactions and error handling and
> binding the result values to instance variables, things would start to
> become interesting. There's nothing wrong with SQL, but most of the lines
> of code here are concerned with other things, and those are the things that
> should be the primary focus of OO-Relational binding.
No!
There is not anything wrong in the automation of the bindings between
the DBMS and the GUI. O/R mapping is not that.
O/R mapping consists in binding the database tables to main memory
network structures like:
class Customer {
int ID;
string Name;
}
class CustomerList {
private ObjectList list;
CustomerList() {list = new ObjectList();}
public void Add(Customer customer) { list.Add(customer) }
public void Delete(Customer customer) { list.Delete(customer) }
}
That is what is wrong.
> > With O-R mappers you hide a high level declarative interface (SQL)
> > behind a primitive procedural interface (3GL).
> >
> Does anything I've written above suggest that's what I do?
No, but O/R mapping consist in that and I am talking about O/R
mapping.
> > But the API is only a mechanism to submit SQL queries and to return
> > the results. It is not a very important issue.
> >
> In a data processing application written in C, C++, Java, etc., the number
> of lines of code to do these things could be very large.
It is one of the reasons because I don't use that languages. In Delphi
and Visual Basic the number of code lines to do these things is zero.
> And it's all
> stupid code. That's what object-relational mapping abstractions are, or
> should be, about.
We are talking about different things. O/R mapping is not that, O/R
mapping is a wrong way to do that, which consists in the creation of
superfluous main memory network structures (called business objects),
and in binding them to tables.
> Personally, I don't want to write a single line of code
> to put a date variable from a SQL result set into a C# DateTime property,
> repeated many times over for all of the other variables.
Me too. I only need to bind a SQL attribute to a DateTime edit box
with a couple of mouse clicks.
> > No, object-relational mapping consist in the attempt to equate classes
> > and tables, which is a big blunder. Classes are the same as database
> > domains. Object-relational mapping is a fatally flawed concept.
> >
> Object-relational mapping is about mapping the results of SQL queries to the
> properties of in-memory objects.
This is too general. To map a table directly to a visual control is
not called O/R mapping.
See this:
Often, the interface for object-relational mapping products is the
same as the interface for object databases.
By object databases they mean network databases. That's what is wrong.
> I agree with you that mapping objects
> one-to-one with individual database tables is a bad idea.
As bad as mapping objects one-to-many with multiple database tables.
> I agree that
> there have been products that required this, and I agree that they were bad
> products. How is it that you came to believe that that was all that
> object-relational mapping was about?
All I readed about O/R mapping was about that, and I readed a lot. I
can provide dozens of links if you want.
This is probably the worst crap I have found:
http://www.agiledata.org/essays/mappingObjects.html
> Look, we need to bring data into in-memory objects so we can process it
No!
We need to bring data into application objects so we can show the data
to the users and get new data from the users. DBMSs are for data
management and applications for presentation and communication.
>, we
> have business requirements, we need to process payrolls, generate extract
> files, calculate how much we have to pay our customers, etc.
DBMSs are intended to calculate these things.
Regards
Alfredo
Actually, I would appreciate it if you would. One of these days I'd like to
do a survey of these things. I am sympathetic to some of your specific
criticisms of object-relational tools, but I find it hard to believe that
all of these tools would be that naive, and I don't see any reason to equate
"object-relational mapping" with "binding an object to a table."
>
> > Look, we need to bring data into in-memory objects so we can process it
>
> No!
>
> We need to bring data into application objects so we can show the data
> to the users and get new data from the users. DBMSs are for data
> management and applications for presentation and communication.
>
> >, we
> > have business requirements, we need to process payrolls, generate
extract
> > files, calculate how much we have to pay our customers, etc.
>
> DBMSs are intended to calculate these things.
>
Suppose I want to compute the profit and loss for all the trades that have
been booked through a trading system. That means going through all the
trades, valuing them with current market prices if they are standard
products, or imputing prices using theoretical models if they are custom
"over the counter" products. The models used in the latter case may be
fairly complicated, and perhaps use Monte Carlo simulation or other
numerical techniques to compute a price. If I'm doing risk analysis, I may
need to simulate market prices, diffusing them out using stochastic models,
and re-value my trading books 10,000 times or so at those prices. These are
typical examples of data processing in the financial world
Now, how would I do all that on the DBMS? And why would I want to? And jus
t to note, nobody does all that on the DBMS, and it's unlikely that
everybody doing these things would be wrong.
Regards,
Daniel Parker
Ok, I will do when I have some time.
> I am sympathetic to some of your specific
> criticisms of object-relational tools, but I find it hard to believe that
> all of these tools would be that naive
Do you know a tool that it is not?
> Suppose I want to compute the profit and loss for all the trades that have
> been booked through a trading system. That means going through all the
> trades, valuing them with current market prices if they are standard
> products,
DBMSs are perfect for this.
> or imputing prices using theoretical models if they are custom
> "over the counter" products. The models used in the latter case may be
> fairly complicated, and perhaps use Monte Carlo simulation or other
> numerical techniques to compute a price.
You can implement the simulator as you want and to extend the DBMS
with it. For instance if you use Oracle you can write stored
procedures in Java or PL/SQL.
> Now, how would I do all that on the DBMS?
You have many options. It depends on what DBMS you use and which are
your favourite languages.
> And why would I want to?
Because it is the simplest and the fastest way.
> And jus
> t to note, nobody does all that on the DBMS
I doubt that, I have seen many complex projects in PL/SQL.
>, and it's unlikely that
> everybody doing these things would be wrong.
Everybody was wrong many many times.
Regards
Alfredo
> "Alfredo Novoa" <alf...@ncs.es> wrote in message
> news:e4330f45.04031...@posting.google.com...
>> "Daniel Parker" <danielaparker@spam?nothanks.windupbird.com> wrote in
> message news:<gHs4c.50669$6y1.1...@news20.bellglobal.com>...
>>
>> All I readed about O/R mapping was about that, and I readed a lot. I
>> can provide dozens of links if you want.
>
> Actually, I would appreciate it if you would. One of these days I'd
> like to do a survey of these things. I am sympathetic to some of your
> specific criticisms of object-relational tools, but I find it hard to
> believe that all of these tools would be that naive, and I don't see
> any reason to equate "object-relational mapping" with "binding an
> object to a table."
Daniel, I use Toplink extensively and I would be happy to talk to you about
this...I will be ignoring Alfredo, however.
Okay :-) Do you mind if I start with the issue of caching?
Last time I used TopLink was about four years ago. We were using it in its
default configuration. In this configuration it had a process that was
caching. If somebody performed an update on a table, unknown to TopLink,
and my program attempted to get an object that was bound to that table, I
would get the old data, not the updated data. As I recall, it was not that
easy to turn caching off, although I believe there were work arounds. For
me, this is an example of a tool doing too much, doing favors that are not
helpful or wished for.
I hope you will tell me that this is no longer the behaviour you get with
the default configuration of TopLink. My own view is that caching does not
belong at all in a tool concerned with object-relational mapping. Do you
agree? Disagree?
Regards,
Daniel
Toplink makes all the blunders I talked about. The issue of caching is
irrelevant compared to that.
Regards
Alfredo
1) I only use an earlier version of Toplink because we have an unlimited
use license for it. We decided to stick with that version about the same
time the greedy vendor tried to stick one of our clients with a $500,000
runtime fee. I don't have the version number handy but its 3-4 yrs old.
2) Caching is on by default but can be turned off easily. Its not even a
work around to do so, although I admit the old gui is an absolute buggy
POS. We avoid the gui and configure Toplink programmatically these days.
3) I have never used Toplink in situations where some external app can
alter the table unbenownst to it. In my view, the app *owns* its tables.
So unfortunately, there may be a series of issues I don't know about in
this shared mode.
4) I absolutely disagree that caching is a tool that does not belong in
the mapping. In fact, I believe in buying a boatload of RAM so that the
entire database can live in the cache. (Extra-large dbases, aside.) That
way, there is no mapping performance hit. IMHO, caching should be
available and implemented so as not to be an issue. But see (3).
Well, our first issue of caching is a strikeout. Do I get another at-bat
:-?
I had the same experience 1 year ago, with the latest (at that time) version
of TopLink. 9.0.3, I believe.
> > I hope you will tell me that this is no longer the behaviour you get
> > with the default configuration of TopLink. My own view is that
> > caching does not belong at all in a tool concerned with
> > object-relational mapping. Do you agree? Disagree?
I disagree, because the blunder that leads to O-R mappings leads also to the
need to carefully manage object identity. You have to play endless games
with which version of the Foo class instance I have, which one the cache
has, etc. A nightmare induced by object-think.
> 1) I only use an earlier version of Toplink because we have an unlimited
> use license for it. We decided to stick with that version about the same
> time the greedy vendor tried to stick one of our clients with a $500,000
> runtime fee. I don't have the version number handy but its 3-4 yrs old.
>
> 2) Caching is on by default but can be turned off easily. Its not even a
> work around to do so, although I admit the old gui is an absolute buggy
> POS. We avoid the gui and configure Toplink programmatically these days.
The GUI has improved, but the concepts are still POS.
> 3) I have never used Toplink in situations where some external app can
> alter the table unbenownst to it. In my view, the app *owns* its tables.
You're so very wrong. The business owns its data. The apps are leasing them,
and have to abide by the rules or get evicted, right? What about 2 apps
which use the same table - which owns it?
- erk
This argument (aside from its other merits or lack thereof) sounds much like
any quack's argument: "Why, you confounded unbelievers lack the ability to
think abstractly (or concretely) about the green mutant ninja fairies
floating around my head!" At issue is the valud of the concept itself, not
whether the mechanics are understood. It's the binding that don't work so
well.
> This is probably the worst crap I have found:
>
> http://www.agiledata.org/essays/mappingObjects.html
hahahaha - I agree! Ambler writes some seriously vacuous garbage (that I
read for laughs), but this is his all-time worst article. Fowler is much
more coherent and much better, but when objects meet the database, brains
seem to melt.
Do you regard caching of objects as an essential part of object-relational
mapping, to support say the concept of object identity, or just as a
desirable part, for performance reasons as you suggest above?
If I have two threads that use two trade objects, that represent the same
employee in the sense that they have the same trade id, I don't care that
they exist as two separate instances. In my case, synchronization of the
values of the trade instances would take place via the database, and any
instance in memory is a relatively short lived snapshot that represents the
database values at the time that the instance was created.
Would you be concerned about having two separate trade instances for the
"same" trade in your process space? I suspect your answer will be yes. But
if so, what notion of object identity would you have if you were working in
a globally distributed environment, with offices in London, New York and
Tokyo? I recognize that there are complicated approaches that address this
issue (not very well in my opinion), but I'm fairly sure TopLink doesn't
support this. The database centric approach, on the other hand, offers an
uncomplicated and widely understood solution.
On the issue of performance, I have to say that some of the slowest systems
I've ever seen were ones that used excessive caching. There are many cases
where I absolutely do want to cache. If I'm performing a portfolio
evaluation of 30,000 trades, for example, what would be the point of caching
them? I'm only going to be visiting each of them once.
Regards,
Daniel Parker
> There are many cases where I absolutely do want to cache
uh, oh, read that as "do NOT"
Daniel
> "Rich MacDonald" <rich@@clevercaboose.com> wrote in message
> news:Xns94B0F0BBC1A4Bri...@24.94.170.87...
>> "Daniel Parker" <danielaparker@spam?nothanks.windupbird.com> wrote in
>> news:slO5c.15510$E71.9...@news20.bellglobal.com:
>>
>> > I hope you will tell me that this is no longer the behaviour you
>> > get with the default configuration of TopLink. My own view is that
>> > caching does not belong at all in a tool concerned with
>> > object-relational mapping. Do you agree? Disagree?
>
> I disagree, because the blunder that leads to O-R mappings leads also
> to the need to carefully manage object identity. You have to play
> endless games with which version of the Foo class instance I have,
> which one the cache has, etc. A nightmare induced by object-think.
You don't need to care which instance is in the cache. (Unless your
tables can be updated independently of Toplink, you don't need to even
know about caching.) You do have to care about which version of the
instance you have. This can be tricky and lead to bugs. Therefore, it
pays to have a good pattern and stick to it. Since you're clearly a CRUD
thinker, let's go with this. In my CRUD apps, I have a PersistenceServer
singleton wrapped with PersistenceSession objects for each user. (Think
of the PersistenceSession as a dbase connection with an OO facade.) All
access goes through the PersistenceSession. You have two basic options:
(1) Get a read-only copy to view, store the updates in the gui fields,
then when the user clicks the OK button, "register" the read-only copy
to get an edittable copy, copy the updates to the edittable copy, then
commit. On cancel, do nothing. Or (2) start with a registered copy and
change it directly, commit it when the user clicks ok and rollback when
the user clicks cancel. Both options work fine with pros and cons. You
do have to be careful when editting an intermediate node in a larger
tree, which is where most bugs will bite you.) I use (1) when possible
and (2) when the model is sufficiently complicated that I need to update
it directly to access the dependent changes.
I reject your object-think nonsense.
>> 2) Caching is on by default but can be turned off easily. Its not
>> even a work around to do so, although I admit the old gui is an
>> absolute buggy POS. We avoid the gui and configure Toplink
>> programmatically these days.
>
> The GUI has improved, but the concepts are still POS.
Deep. I care about productivity.
>> 3) I have never used Toplink in situations where some external app
>> can alter the table unbenownst to it. In my view, the app *owns* its
>> tables.
>
> You're so very wrong.
No, you need to be more careful. I just told you I don't use Toplink in
situations where multiple apps access the data.
> The business owns its data. The apps are leasing
> them, and have to abide by the rules or get evicted, right?
A good percentage of my projects have "data rules" which would bring any
RDBMS to its knees and/or would require the ugliest POC write-once-
update-never SQL. We're playing in different ballparks.
> What about
> 2 apps which use the same table - which owns it?
I'd work hard to avoid this situation, first of all, since its a
nightmare waiting to happen. Failing that I'd be very careful in my use
of Toplink. And I'd write a bunch of automated tests to be sure.
Regards,
Daniel Parker
> "Rich MacDonald" <rich@@clevercaboose.com> wrote in message
> news:Xns94B0F0BBC1A4Bri...@24.94.170.87...
>>
>> 4) I absolutely disagree that caching is a tool that does not belong
>> in the mapping. In fact, I believe in buying a boatload of RAM so
>> that the entire database can live in the cache. (Extra-large dbases,
>> aside.) That way, there is no mapping performance hit. IMHO, caching
>> should be available and implemented so as not to be an issue. But see
>> (3).
>>
>> Well, our first issue of caching is a strikeout. Do I get another
>> at-bat
>> :-?
> Hold on, we're not done yet! I have some questions.
:-) I wasn't trying to bail.
> Do you regard caching of objects as an essential part of
> object-relational mapping, to support say the concept of object
> identity, or just as a desirable part, for performance reasons as you
> suggest above?
Desirable. Its strictly a performance issue. Ideally, you could even
envision a cache that was smart enough to know when the tables changed
independently.
> If I have two threads that use two trade objects, that represent the
> same employee in the sense that they have the same trade id, I don't
> care that they exist as two separate instances. In my case,
> synchronization of the values of the trade instances would take place
> via the database, and any instance in memory is a relatively short
> lived snapshot that represents the database values at the time that
> the instance was created.
One of the powerful benefits of a Toplink is that we can both work with
separate instances of the object then you automatically get updated when
I change mine...if that is the desired functionality. My company has a
product that facilitates client-server over the internet, so this
"sharing" can automatically occur across multiple boxes, i.e., pushing,
not polling.
As for Toplink, there is an instance in memory snapshotting the state
when you read from the cache/dbase. There is an instance in memory
representing your changes. When you commit, those instances are
reconciled, updates are committed to the dbase, and the final instance
kept in the cache for the next access. This can occur across multiple
users as well. Can be lots of instances :-)
> Would you be concerned about having two separate trade instances for
> the "same" trade in your process space? I suspect your answer will be
> yes.
Nope. These instances and more all occur with Toplink anyway. You have
to learn that model and live with it.
> But if so, what notion of object identity would you have if you
> were working in a globally distributed environment, with offices in
> London, New York and Tokyo? I recognize that there are complicated
> approaches that address this issue (not very well in my opinion), but
> I'm fairly sure TopLink doesn't support this. The database centric
> approach, on the other hand, offers an uncomplicated and widely
> understood solution.
There is the "one true" object identity (primary key) which is reduced
to a mental concept in Toplink, since you'll have several instances of
it anyway. The fact is that if you're going to use OO in this
environment you'll be working with multiple instances and it will be
complicated. No escaping that. My point is that Toplink removes the
multi-year development issues we all face when we deal with this kind of
app. Granted, the "identity is the single row in the single table" is
another way to deal with it and it is uncomplicated and widely
understood. However, factor in transactions that multiple users will
require when simultaneously accessing and updating that single row,
global performance needs requiring multiple dbases and replication, and
its no longer uncomplicated or widely understood either :-)
> On the issue of performance, I have to say that some of the slowest
> systems I've ever seen were ones that used excessive caching. There
> are many cases where I absolutely do want to cache. If I'm performing
> a portfolio evaluation of 30,000 trades, for example, what would be
> the point of caching them? I'm only going to be visiting each of them
> once.
Great point. Toplink caching works best with CRUD and short-lived
transactions. My greatest Toplink disaster was using it for a migration
app where I had to copy one multi-million row dbase to another. The two
schemas were so diverse that I absolutely needed to use objects as
intermediates, i.e., dbase1->object1->translation->object2->dbase2. But
I use toplink as the mapping in both ends and it was awful when scaled
to millions of objects. Just as your original point addressed, Toplink
did some things automatically that I didn't want it to do and could have
done *much* better with hand-rolled native sql. I had more toplink
problems than translation problems, and the latter was hard enough :-)
Final point: Toplink is a pig in terms of resources, no question about
it. And it has a difficult learning curve. But I use it for two main
reasons: (1) When it fits, I can leave all alternatives in the dust in
terms of developer productivity, i.e., I can map objects to dbases fast
and I can refactor this mapping fast. (2) Implementing sophisticated
multiuser client-server apps that require persistence is no easy task;
if I rolled my own framework to make me more productive I'm pretty sure
I'd essentially spend a few man-years re-implementing what Toplink
already does. Different, for sure, but not sufficiently different to
justify that amount of time.
Oh, good, so we can dispense with this issue :-)
> Granted, the "identity is the single row in the single table" is
> another way to deal with it and it is uncomplicated and widely
> understood.
Who said anything about "single row", "single table"?
> However, factor in transactions that multiple users will
> require when simultaneously accessing and updating that single row,
> global performance needs requiring multiple dbases and replication, and
> its no longer uncomplicated or widely understood either :-)
Well, if we are talking trades, a single exotic trade with four legs and
amortizing notionals and customized cashflows could be represented by
hundreds or more rows in a dozen or so tables. So let's drop the "single
row" business.
But simultaneous access and updating of such trades, multiple databases in
different parts of the world and replication, I've been involved both in
building systems like this, and integrating other vendor's systems like this
into the banking enterprise. This is the world that I know.
>
> Final point: Toplink is a pig in terms of resources, no question about
> it. And it has a difficult learning curve. But I use it for two main
> reasons: (1) When it fits, I can leave all alternatives in the dust in
> terms of developer productivity, i.e., I can map objects to dbases fast
> and I can refactor this mapping fast.
Okay.
> (2) Implementing sophisticated
> multiuser client-server apps that require persistence is no easy task;
> if I rolled my own framework to make me more productive I'm pretty sure
> I'd essentially spend a few man-years re-implementing what Toplink
> already does. Different, for sure, but not sufficiently different to
> justify that amount of time.
How different? What would your ideal object-relational mapping tool look
like?
Daniel
Daniel
> "Rich MacDonald" <rich@@clevercaboose.com> wrote in message
> news:Xns94B18E628DDC4ri...@24.94.170.86...
>>
>> Granted, the "identity is the single row in the single table" is
>> another way to deal with it and it is uncomplicated and widely
>> understood.
>
> Who said anything about "single row", "single table"?
I used quotes, but still that was an unnecessary restriction. I didn't
actually mean "single row". You know what I meant :-)
>> However, factor in transactions that multiple users will
>> require when simultaneously accessing and updating that single row,
>> global performance needs requiring multiple dbases and replication,
>> and its no longer uncomplicated or widely understood either :-)
>
> But simultaneous access and updating of such trades, multiple
> databases in different parts of the world and replication, I've been
> involved both in building systems like this, and integrating other
> vendor's systems like this into the banking enterprise. This is the
> world that I know.
I know it when there are users involved in short-term gui interactions --
crud with push. This is different from what you face, though. Honestly,
with your integration and legacy issues, I'd consider *not* using Toplink
-- your objection that it "helps" you in ways you'd rather not be helped is
very significant in that world. The good help probably doesn't outweigh the
bad help (some help is fatal) and the need for custom solutions makes
Toplink too risky -- you cannot risk not being able to take *everything*
under your control if needed.
>> (2) Implementing sophisticated
>> multiuser client-server apps that require persistence is no easy
>> task; if I rolled my own framework to make me more productive I'm
>> pretty sure I'd essentially spend a few man-years re-implementing
>> what Toplink already does. Different, for sure, but not sufficiently
>> different to justify that amount of time.
>
> How different? What would your ideal object-relational mapping tool
> look like?
No private methods, for one thing. Source code, for another.
Ok, the mapping between OO and relational is a trivial area: you may wind
up making a few compromises on both ends, but no big deal. This takes care
of the reading and writing of objects. The managing of multiple instances
and writing changes to the correct instance could be made better. My number
one annoyance with Toplink and my biggest source of bugs is as follows:
I have a collection of linked objects read as read-only. Now I'm going to
make a change. I start a transaction. I take an instance and register it
with the session for editting. Toplink returns me a *copy* of the instance.
I have to make changes to this *copy*. Then I commit the transaction.
The "mistake" is that I have to make changes to the copy, not the original.
No problem when I update that instance's attributes, but when I traverse
from that instance and alter some related instance I have to be very
careful. Each instance that I obtain as I traverse is also a copy. The
problem is that if I alter a relationship between two instances I have to
ensure that I update the relationship with two *copies*, i.e., objects that
the session has already registered. So if I have not yet traversed to that
second instance (and thus automatically obtained the copy), I first have to
register it (and use its copy) as well. This is ugly code. If I screw up,
if I'm lucky Toplink throws an error (cannot associate two objects where
one is not registered), but Toplink may also say nothing yet not store the
update, which is serious.
The *ideal* approach would be to register the object for update yet allow
me to continue to update the *original(s)*, rather than the copies.
(Alternatively, to allow me simply to change the original without
registration, but that will incur a performance hit as the tool will then
always have to register everything before it gives me the instances.) This
will remove the ugly code and allow me to be much lazier.
I say "ideal", but this is thinking as a lazy programmer who perhaps wants
too much from his library. What I want may not be possible without a major
performance hit. Basically it will require the tool to clone every instance
before it gives them to me, then check everything to see what has changed.
And it really requires checking everything. Or as a compromise, require the
programmer or compiler to mark the altered objects as dirty. So really,
there doesn't seem to be a practical ideal unless you modify the compiler
to insert those necessary hooks invisibly to the programmer.
I suppose we're getting back to the old saw, that a library cannot be all
things to all people, and that as you automate one part you make other uses
difficult or impossible. So there cannot be an ideal, in which case the
best compromise is to provide some capabilities but require more out of the
programmer than is strictly required. Or perhaps if I just had the Toplink
source code and a few projects to provide refactoring needs, then I could
give you a better answer.
Sorry, I'm having some trouble following this, starting from "if I alter the
relationship with two instances." Would it be possible to show a short
fragment of code that illustrates this point?
Thanks,
Daniel Parker
Object A has an attribute X which points to object B. Both A and B are
non-primitive, i.e., are defined in the Toplink mapping. Both A and B
has been persisted before. To update the association I have to write
something like:
Object a1 = toplinkSession.register(a);
Object b1 = toplinkSession.register(b);
a1.setX(b1);
instead of:
Object a1 = toplinkSession.register(a);
a1.setX(b);
As a code fragment, this looks innocuous, but it isn't. If I register a1
in one method, the call to setX can be far away in some other method.
And I have to ensure that I use the same instance of toplinkSession.
This means that I have to pass toplinkSession around. I have a pattern
to deal with this, but I also have to make sure I don't register an
object more than once. If in some other method I have something like:
b.setPrimitive(somePrimitive);
First I'll have to use b1 instead of b. Second I cannot write:
Object b1 = toplinkSession.register(b);
b.setY(c);
and use it with the original code fragment above, because b will be
registered twice.
Hopefully you can see all the coupling that is occurring. This coupling
dictates the code and is more than just aesthetically ugly. Patterns
help to minimize this coupling, but it cannot be eliminated and is a
likely source of bugs.
Can you refresh my memory on one other aspect of TopLink? Do the A and B
classes need to extend/implement any TopLink classes/interfaces? Do the
files containing the A and B implementations need to import any TopLink
classes? Or is it enough for TopLink to use reflection on A and B
supplemented by configuration files, so that the A and B implementations can
be kept "pure."?
Daniel
> hahahaha - I agree! Ambler writes some seriously vacuous garbage (that I
> read for laughs), but this is his all-time worst article. Fowler is much
> more coherent and much better, but when objects meet the database, brains
> seem to melt.
Much better than Ambler does not mean good. In respect to databases,
Fowler is lost in outer space.
Regards
Alfredo
> Thanks. So we have a complex storage scheme, with lots of
> associations, the need to update one or more parts of this scheme, the
> need to do the updates within a single transaction, and the wish that
> when we commit, only the parts that have been actually changed will be
> updated in the database. I think that defines the problem of greatest
> interest here. Do you concur?
Yes
> Can you refresh my memory on one other aspect of TopLink? Do the A
> and B classes need to extend/implement any TopLink classes/interfaces?
They must support an empty constructor. That is the only requirement. Each
attribute being mapped can be immediate or lazy. If immediate, you don't
need anything else. If lazy, the attribute is a toplink class with a
getValue/setValue interface. I tend to use lazy, because you don't have to
load the complex class all at once (and everything it links to), plus
toplink doesn't have to walk the instances when checking for updates if you
haven't traversed that association (you can't have changed something if you
haven't accessed it). You can use public access to the attributes or define
get/setters for toplink. Over time, I've settled on a pattern to use public
access for toplink and get/setters for the app which keeps things separate
(when I use get/setters for toplink and the app I would invariably want to
do something special within my get/setter for the app and I would screw up
toplink; giving toplink public access makes it simple and keeps things
separate).
> Do the files containing the A and B implementations need to import
> any TopLink classes? Or is it enough for TopLink to use reflection on
> A and B supplemented by configuration files, so that the A and B
> implementations can be kept "pure."?
>
As stated above, you can keep A and B pure if you want. In practice I use a
toplink get/setter class for lazy attributes. I'll use immediate attributes
for primitives and lazy attributes for most toplink classes.
I've also developed a set of templates/macros in Eclipse for this. So, for
example, if A and B have a 1-N association (using an Arraylist for B), I
run the "one-to-many-Toplink" macro on A and the "many-to-one-Toplink"
macro on B. Everything is setup so I just have to type one word into each
macro, i.e., "B" and "A" (the class names) to get the following:
public class A {
public A() {
super();
}
//
-------------------------------------------------------------------------
// one-to-many B
public ValueHolderInterface manyBHolder = new ValueHolder(new
ArrayList());
public ArrayList getBs() {
return (ArrayList) manyBHolder.getValue();
}
public int getBCount() {
return getBs().size();
}
public B getB(int i) {
return (B) getBs().get(i);
}
public void setBs(ArrayList many) {
removeBs();
addBs(many);
}
public void addBs(ArrayList many) {
Iterator iter = many.iterator();
while (iter.hasNext()) {
B item = (B) iter.next();
addB(item);
}
}
public void addB(B one) {
one.setA(this);
}
public void removeB(B one) {
one.removeA();
}
public void removeBs(ArrayList many) {
Iterator iter = many.iterator();
while (iter.hasNext()) {
B item = (B) iter.next();
removeB(item);
}
}
public void removeBs() {
ArrayList oldList = (ArrayList) getBs().clone();
removeBs(oldList);
}
//
-------------------------------------------------------------------------
}
public class B {
public B() {
super();
}
//
-------------------------------------------------------------------------
// many-to-one A
public ValueHolderInterface oneAHolder = new ValueHolder();
public void setA(A one) {
A prevOne = getA();
if (prevOne != null) {
prevOne.getBs().remove(this);
}
oneAHolder.setValue(one);
if (one != null) {
one.getBs().add(this);
}
}
public A getA() {
return (A) oneAHolder.getValue();
}
public void removeA() {
setA(null);
}
//
-------------------------------------------------------------------------
}
Its quite a bit of code, but its all automatically generated for the price
of a few keywords. Plus its debugged :-) And if I have to refactor this
later, I simply delete all the code and rerun the macro.
So easy to criticize others when you have no answers of your own. FWIW,
I've learned a lot from both Ambler and Fowler. I've learned nothing from
you. Where is your website of brilliant solutions :-?
> So easy to criticize others when you have no answers of your own.
I have very good answers to many Information Systems development
issues.
> FWIW,
> I've learned a lot from both Ambler and Fowler.
I can believe that you were misleaded by them.
> I've learned nothing from
> you.
Because your zealotery closes your mind to any new knowledge.
> Where is your website of brilliant solutions :-?
I don't have one, but you could learn a lot in www.dbdebunk.com if you
were free of zealotery.
Regards
Alfredo
Alistair Cockburn once wrote an article where he lamented the inability of
people coming from different worlds - OO, databases, etc. - to talk to each
other, and suggested that one of the greatest contributions individuals
could make to world peace was to attempt to become multilingual on some of
these matters.
But one quick suggestion, instead of posting about how Fowler "does not have
a clue on he talks about" and that he "is lost in outer space", instead of
doing that, present something from his writings that you disagree with and
argue about that instead. Who knows, may you'll find that it is possible to
find happiness on a lost spaceship. But distinguishing between the author
and the writng is the essence of civilized debate.
Regards,
Daniel Parker
>Distinguishing between the author
>and the writng is the essence of civilized debate.
That should be the banner posted above all newsgroups.
Beecauuusssse ..... ???
Elliott
http://www.nizkor.org/features/fallacies/ad-hominem.html
All I can say to that is apparently your ability to objectively know I write
about
is affected by one or more:
~ your negative stance toward me
~ you read me infrequently
Only those could explain that you think I dismiss persons positions on
comp.object
simply by stating what they are. It's ludicrous and even if you asked most
of those
whom think negatively of me, those who read at least 3 out 10 of my posts,
would agree that at least 8 out of 10 times when I make personal attacks, it
is
goes along with reasons. And in most cases detailed, very specific, very
concrete
reasons.
Let's look at messages where I got personal just Friday and today the last 2
days I posted.
*******************************************
#1
Ronald E Jeffries" <ronje...@acm.org> wrote in message
<< "Universe" <univ...@tAkEcovadOuT.net> wrote:
<<<
Historically (the last ~3 years) most XP'ers and leading XP'er have
EXPLICITLY denied that:
we should always try to have an at least minimally complete overall
(holistic) analysis of all key aspects before implementing the bulk,
or logical high level design heart of a software project.
>>>>
Convenient how with lack of intellectual integrity, you DELETED MY
ESSENTIAL POINT.
Don't want them to compare readings in the listing below with
my statement? Likely, they'll see I'm correct, innit?
For the record, I re-quoted above the widely accepted - both without
and *within* the XP camp - point that Jeffries ludicrously denies:
As I said to Jeffries on denying my main point:
> >> >1) Read more carefully, 2) stop playing games, or 3) openly proclaim
that
> >> >Jeffries XP "unstably" and with the principles of a jelly fish, stands
against
> >> >and for the same aspects of "Y", in the same context, simultaneously.
Jeffries:
> >> Historically I have called you on this many many times, pointing out
> >> every time that the release plan process, which is mentioned in the
> >> very first XP book (and in mine, and in the book Planning Extreme
> >> Programming, ...) is precisely a consideration of all key use cases.
Elliott:
> >I stand by point as overriding and reflecting the main truth about XP.
XP
> >is more than Ronald Jeffries.
> >
> >And **EVERY** other XP'er whose book, paper, column, Letter to the
Editor,
> >and post to Usenet, I have read states what I state above.
EVERYONE except you NOW Jeffries knows this about XP:
<<<
Historically (the last ~3 years) most XP'ers and leading XP'er have
EXPLICITLY denied that:
we should always try to have an at least minimally complete overall
(holistic) analysis of all key aspects before implementing the bulk,
or logical high level design heart of a software project.
>>>>
*************************
Is my personal attack just personal or linked to OO/SW Engineering?
************************
#2
"Jason Nocks" <noc...@sourcextreme.com> wrote in message
news:667ae$405af508$cff54506
> Elliott wrote:
> >"Jason Nocks" <noc...@sourcextreme.com> wrote in message
news:667ae$405af508$cff54506
> >>And, how do you even know when you are done with
> >>analysis? Couldn't you always do more analysis, just to make sure you
> >>haven't missed something?
> > Convergence - Slowed velocity in changes in understanding the domain
> > and use cases - Domain experts on the Analysis team are happy - Etc.
> When I say, "how do you even know when you are done", I am looking for
> something that results in a boolean yes/no response. "Slowed velocity in
> changes" is not the same as "complete". What is the definitive end
> point? Something contractually definable. Something clear, concise, and
> unambiguous. IMHO, this endpoint does not exist (or is arbitrary).
1st Analysis is never "sewn up, jelly tight" *complete*.
2nd Why are up so stressed about "complete" Analysis?
I defined how genuine holistic, MDA RUP handles our Analysis within our
IID - iterative & incremental development.
Holistic, MDA'ers know that due to project feedback, changes in the
domain, changes in use case reqs that both Analysis and Design may
be modified, and even tossed.
Someone told you RUPists requires "Boolean complete* analysis before
the heart of high level production code and you want me to concur
with that mythological fantasy, that lie, that XP "straw man".
*************************
Some might see this as personal. If so is it just about a personal attack?
************************
#3
"Ilja Preuß" <pre...@disy.net> wrote in message
news:c3f3hu$9hm$1...@stu1id2.ip.tesion.net...
> Thomas Gagné wrote:
> > Ilja Preuß wrote:
> >
> >>
> >> So you include the computing space into the "real world"? I don't
> >> think that most people do this if they speak about "modeling the
> >> real world".
> >
> > But the computing world is real. There are disks, directories, and
> > filenames. There are databases, tables, rows, and fields. Accepting
> > them as real-world objects makes using them easier, don't you think?
>
> Probably.
>
> Accepting LSP-violations as real-world problems probably also makes
> developing good software easier.
Garshk! Do you really believe that any models of *really existing* -
physical
and mental - object collaboration are *necessarily* LSP violators?
************************
If this is a personal attack, is it simply a personal attack?
****************************
#5
"Ronald E Jeffries" <ronje...@acm.org> wrote in message
> cy...@hotmail.com (Cy Coe) wrote:
> >
> >Always focusing on the small, never reflecting on the bigger picture.
> Apparently you haven't studied XP much. That's not what we teach,
> that's not what we do. Why do you keep saying it?
> >Splitting hairs. You're still saying that if you take care of the
> >small stuff (ie, coding the individual features well), the big picture
> >(ie., the architecture) will spontaneous emerge, without any
> >deliberate planning. I don't buy it.
> I didn't say spontaneous. In fact I said we /cause/ the good design to
> emerge. Even a small study of refactoring would, I'd think,
> demonstrate how that is done.
> >> We think that planning is important. That's why we plan all the time
> >> during a project, not just at the beginning.
> >Empty rhetoric. You never plan beyond the end of your nose. Once
> >again, you focus on the trees, assuming the forest will take care of
> >itself.
> Baseless accusations. Release plan is beyond the end of the nose.
Because XP release plans may refer to all project use cases doesn't mean
at least minimal overall investigation and analysis of at least all key use
cases has been done. And according to most XP'ers and most XP' leading
lights that such overall analysis is not seen as necessary before tackling
the bulk of production code, nor the heart of high level production code.
And that is hackery.
The keys of hackery are:
~ lack of at least minimal overall study of at least all key use cases
before coding the bulk of all code, and the heart of high level
code.
~ lack of a design plan based upon doing the former that covers at
least all key areas
~ failure to apply the scientific method where what is truth is
determined
by it being upheld in key areas of practice over domain appropriate
time periods. it is not simply whatever works now for me, or my
group.
**************************
Most of the heat is between Coe & Jeffries, I added the unquoted. Is it
a personal attack though taking one side of the heat?
**************************
#6
"Cy Coe" <cy...@hotmail.com> wrote in message
> Laurent Bossavit <lau...@dontspambossavit.com> wrote in message
> > Cy:
> >
> > > You XP'ers are strict segregationists who don't want to dirty
> > > yourselves with understanding the domain.
> > A clever plan. One unfortunately marred by insisting on the physical
> > presence of a domain expert in the room at all times during the project,
> ...the purpose of which is to eliminate the need for the developers to
> become knowledgeable in the domain. Why study when you have the book
> right there? And if your expert will spoon-feed you acceptance tests
> which further insulate you from analysis of the actual business needs,
> all the better.
> > and further flawed by the use of a shared vocabulary understandable by
> > both the domain expert and the segregationists, also known as Metaphor.
Crucial to remember. [XP] Metaphor is [simply] aimed at explaining how
the code system operates, it is not aimed at explaining the domain.
Also even a developer vocabulary of the domain is not OK simply because
it exists. A useful domain vocabulary is based upon at least a minimal
overall, scientific method anchored, understanding of at least all key
facets of the domain--i.e. it is genuinely "holistic".
****************************
Ditto the above:
"Most of the heat is between Coe & Jeffries, I added the unquoted. Is it
a personal attack though taking one side of the heat?"
*****************************
#7
"Robert C. Martin" <uncl...@objectmentor.com> wrote in message
> clint...@hotmail.com (Clint Shank) wrote:
>> "Robert C. Martin" <uncl...@objectmentor.com> wrote in message
> >>
> >> No need to guess. The Release Plan practice is well known and well
> >> documented in the XP materials. Once stories have been gathered and
> >> estimated, the stakeholders and developers meet to plan the next
> >> release. The release is typically 3 months worth of development
> >> effort.
3 months for *each* and *every* use case, for *all* domains, for *all*
projects,
for *time* immemorial?
Shhhrrright, pulllleeez.
Talk about specifics ignoring and hence unscientific dogmatism--thar he
blows.
> >>The stakeholders will choose those stories that provide the
> >> most business value, and whose estimates are compatible with the
> >> release time frame.
But we know that for all time - 3 months.
> >> From those stories the stakeholders will then choose stories for the
> >> next iteration. Once the iteration stories are chosen, development of
> >> those stories can begin.
For which stories can "development" begin, the *current*, the *next*,
the *next to next*, all simply based upon what stories are chosen? What
exactly does "development" entail, mean?
> >I don't have my XP books around, but I think I remember something
> >about software risks given some weight in the planning process. I'm
> >talking about risks pertaining to functionality that isn't the highest
> >priority in terms of business value, but represents some unknowns or
> >big technological risks. I was always confused about how to
> >incorporate these things into the planning. Should they be worked on
> >when the business functionality related to them becomes the highest
> >priority? Or should they be "spike solutioned" earlier, and if so,
> >how do you know when to do them?
> The developers communicate risk in terms of their estimates for the
> stories. A risky story is hard to estimate,
In what way is a risky story hard to estimate for XP'ers?
The industry has already defined "risky" as involving one or more:
a) hard to pin down key aspects of the use case for a variety of reasons
b) requires as yet created technology
c) requires rarely used, complex technology
d) requires very complex technology
The closest the "hard to estimate" comes is to "a)". And we don't know
if that's what XP actually means for "hard to estimate".
> A risky story is hard to estimate, and so the estimate will be high.
"High" exactly how?
This is as clear as mud.
> If the risk is very high, the developers may refuse to
> estimate the story.
?? But it required an estimate by the developers to determine that the risk
for the
use case was "high". So an estimate was *already* undertaken. Again, clear
as mud.
> In that case the customer can ask them to spike
> the story.
The customer should "spike" a lot more with these kind of XP (or only
objectmentor XP) shenanigans going on.
> A spike is a story by itself. It has a cost associated
> with it, and the customer can schedule it like any other story. The
> output of a spike is an estimate for the high risk story.
Whaaaa....?? More and thicker mud. Perhaps mud like consistency with
a lot more organics like carbon and nitrogen waste?
> Thus, it is up to the developers to identify risk, but it is up to the
> customers to schedule when that risk should be resolved. Clearly
> there is a *lot* of dialog between the developers and customers about
> the implications of the risk. Indeed, the developers often stress how
> important it is to resolve certain risks early. The customers take
> this advice under consideration, but may decide to defer the risky
> stories in order to manage political and marketing risks of their own.
Macro policy and methods pathetique.
*************************************
This one is "personal", but is that point of it? To make a personal attack
on RCM or is it mainly getting at OO/SW Engineering issues related to how
we manage and organize release schedules and how we define and
manage risks?
******************************
I don't mind objective criticism, and that helps move things forward, but
please
don't let *subjective* notions make things non-productive and ugly.
Elliott
>
>
> I don't mind objective criticism, and that helps move things forward, but
> please
> don't let *subjective* notions make things non-productive and ugly.
>
> Elliott
Elliot
I was not making any personal attack or critism of *you*. You asked why the
following should be the banner posted above all newsgroups:
> >Distinguishing between the author
> >and the writng is the essence of civilized debate.
And I replied IMO with the reason being that many debates and discussions in
this newsgroup seem to forget this and become Ad Hominem. Well actually I
posted a link to a definition of Ad Hominem .... Ad Hominem was the answer I
was giving to your question. I did NOT reply "Ad Hominem from Elliot".
We are probably all guilty of Ad Hominem to some degree at some time but it
is nice to have a reminder that this is a discussion of ideas and opinions
and not character.
A principle that I try to apply is "Seek First to Understand Before Being
Understood" ... one that I sometimes inadvertently fail at miserably but I
am only doing that best that I can.
Shane
--
"Have no fear" - The Cat In The Hat (Dr Seuss)
> We are probably all guilty of Ad Hominem to some degree at some time but
it
> is nice to have a reminder that this is a discussion of ideas and opinions
> and not character.
Ad hominem isn't a problem in and of itself, but rather it's the disrespect
of facts and logic in favor of emotional attachment to favorite notions that
causes the ad hominem, as well as causing a host of other logical fallacies.
Shayne Wissler
> Elliot
Ahhh, it's clear now isn't it with "Elliot", just below my "Elliott".
You are really making an attempt to demonstrate that anything personal
should be avoided are you not? You are not so subjective that you would
be a hypocrite now are you?
The obvious misspelling of my name is a clear signal that your criticizing
me about being personal is simply a misdirection as you attempt actually
to personally attack me.
And hey I don't buy the I "overlooked it", and "I didn't know it meant that
much" spiel. Especially given that you have explicitly said you dislike
me not too long ago.
> I was not making any personal attack or critism of *you*. You asked why
the
> following should be the banner posted above all newsgroups:
> > >Distinguishing between the author
> > >and the writng is the essence of civilized debate.
> And I replied IMO with the reason being that many debates and discussions
in
> this newsgroup seem to forget this and become Ad Hominem. Well actually I
> posted a link to a definition of Ad Hominem .... Ad Hominem was the answer
I
> was giving to your question. I did NOT reply "Ad Hominem from Elliot".
["Elliot" -ell]
Well as one whom might be accused of ad hominem by those ill-informed by the
common misconception of the term ad hominem, I felt it was in the better
interest
of the group to demonstrate why that would be false.
But just WHERE is all this PERSONAL attack UNRELATED to discussion on
comp.object?
> We are probably all guilty of Ad Hominem to some degree at some time but
it
> is nice to have a reminder that this is a discussion of ideas and opinions
> and not character.
>
> A principle that I try to apply is "Seek First to Understand Before Being
> Understood" ... one that I sometimes inadvertently fail at miserably but I
> am only doing that best that I can.
However I'll make the daring claim that to simply criticize ideas without
relating to nearby concrete examples is failing to be as effective as might
be in supporting, reinforcing, enhancing, and creating ideas, views,
hypothesis, theories principles, heuristics, etc.
Quite often the behavior, practice, thinking, responses, remarks of people
right here on comp.object are very useful examples and illustrations of what
is not only wrong and, but right.
While we are weak on the "right" part, it is no vice to point out personal
wrong in
support of social - in this case software, especially OO engineering -
truths, or as part
of the process of finding the truth.
Elliott
--
XP Craftistry is mostly wrong as are the perceptions of most its
adherents. Just a fact.
In life there is truth<=>falsehood. And XP is *generally* on
the right (wrong) side of that dialectic in most cases.
Actually that was a completely honest mistake. But if you wish to imagine
different then I cannot do much about that. I actually suffer the
misspelling of my name all the time ... I generally do not get too upset by
it.
That's because you're not a troll of dubious mental stability.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
Not surprised you personally attack me unattached to substance. Your
intellectual integrity and honesty went out the window some weeks with
your spineless, midget refusal to condemn RCM's racism.
Elliott
And if I'm so mentally unstable then you'd think "controvert"ing my
philosophical, social science based analysis of a little code, a little
design, a little analysis, anti-genuine objective whatever works for now,
no mandated overall system design spontaneity worshiping ('cuz
milquetoast lets call this and that, x and y metaphor doesn't count)
XP would be a piece of cake.
You wouldn't limit yourself to this and that nickel and dime, opportunistic,
flip-flopping trying to iron out differences amongst the uncertified, inept
"beauticians" trying to paint a half-way decent looking face on that pig hag
XP bag of hackery that you all snag and shag.
Try to fool yourself, if you want, but we all know that it *does* matter.
Goedel proved that nothing exists in isolation and nothing can be genuinely
proven true in and of itself.
Yet on key underlying philosophic-social software engineering matters,
I hear of nothing from you and others of XP direction but the crude, rude,
"stipule" and crickets chirping. Subjective outbursts of anger in lieu of
even _attempts_ at thought out scientific statements of substance _on_
substance.
Finally if I'm the one whose mentally unstable, how is it I can explain and
illustrate the subjective, coder-egocentric, regressive, psycho-neurotic XP
mindset and mental workings in scenically exquisite detail, but for you
in terms of me its zip, zero, nada?
Elliott
--
What Ever Works For Me For Now Is Far From Mental Stability
>>Distinguishing between the author
>>and the writng is the essence of civilized debate.
>
>
> That should be the banner posted above all newsgroups.
Yeah, that one is good.
Jeff Brooks
Curious, what does that mean, convey, denote to you?
Frankly, I'm baffled. Is this like an XP gang hand sign or what?
Really. If it can 1) first of all be rationally explained, and 2) explained
as
something that enhances comp.object as a forum for advancing the theory
and practice of OO software engineering, then I'm all for it.
Otherwise, where do you all handout the "ears". <g>
[Read this as the challenge it is please, _not_ a troll. Thanks.]
>> That's because you're not a troll of dubious mental stability.
>
>Not surprised you personally attack me unattached to substance. Your
>intellectual integrity and honesty went out the window some weeks with
>your spineless, midget refusal to condemn RCM's racism.
Mr Mingins stated that he didn't get upset under certain
circumstances, and I suggested that was because he was not a troll of
dubious mental stability.
I have made no statements about you, and just why you would so quickly
adopt the banner of "troll of dubious mental stability" escapes me,
although if you wish to carry that banner I shall certainly support
you in that endeavor. I feel sure that you could succeed admirably in
that quest.
As for Bob Martin, I know him well, and know that he is not a racist.
As for spineless, my spine works rather well considering my advanced
age -- I can surely kick as high as your head. Which, assuming you to
be of approximately average height, also should allay any concerns
about the possibility of my being a little person.
However, any little people here on the forum may wish to inquire why
you are using their small stature in such an apparently pejorative
fashion. Perhaps we'll leave that topic for a different forum. See me
privately in my office if you wish to discuss that further.
>And if I'm so mentally unstable then you'd think "controvert"ing my
>philosophical, social science based analysis of a little code, a little
>design, a little analysis, anti-genuine objective whatever works for now,
>no mandated overall system design spontaneity worshiping ('cuz
>milquetoast lets call this and that, x and y metaphor doesn't count)
>XP would be a piece of cake.
>
>You wouldn't limit yourself to this and that nickel and dime, opportunistic,
>flip-flopping trying to iron out differences amongst the uncertified, inept
>"beauticians" trying to paint a half-way decent looking face on that pig hag
>XP bag of hackery that you all snag and shag.
>
>Try to fool yourself, if you want, but we all know that it *does* matter.
>Goedel proved that nothing exists in isolation and nothing can be genuinely
>proven true in and of itself.
>
>Yet on key underlying philosophic-social software engineering matters,
>I hear of nothing from you and others of XP direction but the crude, rude,
>"stipule" and crickets chirping. Subjective outbursts of anger in lieu of
>even _attempts_ at thought out scientific statements of substance _on_
>substance.
>
>Finally if I'm the one whose mentally unstable, how is it I can explain and
>illustrate the subjective, coder-egocentric, regressive, psycho-neurotic XP
>mindset and mental workings in scenically exquisite detail, but for you
>in terms of me its zip, zero, nada?
Defense rests.
Actually, you did, by implication. But the closer to the truth you are, the
less ethical it would be to make statements like this.
Daniel
Unfortunately none of the above works for .NET
Thanks for attempt :-)
This isn't the only time Jeffries has taken pot shots at Universe and then
later denied doing so. I can understand the reason for the pot shots, what I
don't get is why he pretends he didn't take them.
Shayne Wissler
Thank you very much for the really helpful response
Alex
I feel myself guilty and have to apologize to all the people who were
abused in this thread, especially to Martin Fowler.
Alex
> What is interesting, though, is that when these authors are
> addressing other subjects about which they are less enthusiastic,
> particularly OO and XML, they often fall short of the very high standards
> they demand on discourse about database management systems.
I strongly disagree. It is exactly the contrary. They mantain their
very high standards when they talk about messy disciplines like OO,
and they find flaws and inconsistencies never discussed by the OO
autors.
> For example,
> they at one time posted a link to Topmind's web site as a criticism of OO,
A mistake they corrected in a short. Nobody is perfect, but wise
people is able to rectify.
> They are currently posting a link to an
> article called "The Myth of Self-Describing XML", which talks about the
> "myth" by "many in the IT industry", that XML is somehow "self-describing in
> a way that can always be discerned by the receiving system" and that
> "nothing could be further from the truth."
The myth exists, and it needs to be debunked. I have seen people
trying to sell that.
> Clearly, those "many in the IT
> industry" have never read a single book or article about XML, and if there
> were individuals that held such views, they would be eminent candidates for
> debunking on an XML site.
But the fact is that XML sites do nothing to debunk that widely
spreaded myth.
> Alistair Cockburn once wrote an article where he lamented the inability of
> people coming from different worlds - OO, databases, etc. - to talk to each
> other, and suggested that one of the greatest contributions individuals
> could make to world peace was to attempt to become multilingual on some of
> these matters.
As an OO coder I try to have a good knowledge on data management, and
I am suprised and disapointed about the closed minds, zealotery and
incompetence of many of my coleagues.
> But one quick suggestion, instead of posting about how Fowler "does not have
> a clue on he talks about" and that he "is lost in outer space", instead of
> doing that, present something from his writings that you disagree with and
> argue about that instead.
I did that many times. His fundamental mistake is that he tries to use
OO to manage data, and OO is not intended to do that. We have a lot
better way to manage data than to manage data in the applications
using network structures and procedural code.
> Who knows, may you'll find that it is possible to
> find happiness on a lost spaceship.
He migth be very happy, but what about the legions of coders misleaded
by people like him?
See a recent thread with title "Could use help modeling something" for
an example.
> But distinguishing between the author
> and the writng is the essence of civilized debate.
I distinguish that. It is a fact that his writings misinform. It may
have 2 different explanations: ignorance or evilness. I always choose
the first by default.
Regards
Alfredo
And you like Jeffries lacking intellectual integrity and honesty, and
incapable of
effectively contradicting my standpoints, takes slimeball ad hominem shots
like
the above unrelated to sw engineering matters of substance. You still need
to
grow up, get over your ego and overcome your ugly psycho-neurosis.
Elliott
--
http://www.univercenet.net
Enumerative (quantitative; metric) reasoning is only an
adequate mental tool under the severe boundary condition
that we only use it very moderately. We should appreciate
abstraction (qualitative thinking) as our main mental technique
to reduce the demands made upon enumerative reasoning."
~ EW Dijkstra
But life is contradictory.
Elliott
<snip>
>> I can understand the reason for the pot shots,
<snip>
> And you like Jeffries lacking intellectual integrity and honesty, and
> incapable of
> effectively contradicting my standpoints, takes slimeball ad hominem shots
> like
> the above unrelated to sw engineering matters of substance. You still
need
> to
> grow up, get over your ego and overcome your ugly psycho-neurosis.
Case in point.
Shayne Wissler
I always feel that the truth needs saying. Your suggestion that
sometimes it does not is thought-provoking and perhaps you're right.
Sometimes I just can't resist rising to the bait. I plead youthful
inexperience and ask for mercy because of my long and faithful
service.