dbTalk Databases Forums  

OOOS

comp.databases.object comp.databases.object


Discuss OOOS in the comp.databases.object forum.



Reply
 
Thread Tools Display Modes
  #41  
Old   
Bob Badour
 
Posts: n/a

Default Re: OOOS - 02-09-2004 , 09:36 AM






"Alfredo Novoa" <alfredo (AT) ncs (DOT) es> wrote

Quote:
"Carl Rosenberger" <carl (AT) db4o (DOT) com> wrote

Alfredo Novoa wrote:
Which other active OO database would you consider more
'advanced'?

DBMS, not database. More advanced OO DBMSs are Dataphor, FirstSQL and
even Oracle and DB2.

Interesting news.

- Does any of the above engines manage object identities within the
client?
For your understanding what I mean: If I access an object through
multiple
paths (queries, navigation) will I get back the same object every time?

Utterly incoherent question.
Not if one automatically assumes a network model and location based identity
as Carl does.


Quote:
- What kind of object caching mechanism is used to provide this feature?
Again, only relevant to network model databases. Better databases than
network model have better caching options available.


Quote:
Weak references? How does the mechanism integrate with garbage
collection?

Why any references at all? Again, Carl implicitly assumes the user is stupid
enough to want to chase pointers.


Quote:
- What kind of object-level locking is provided?

More nonsenses.
Again, Carl implicitly assumes a total lack of physical independence. Thus,
if one has a logical object one also has a physical resource that requires a
physical lock. What makes Carl worse than most is his ignorance is willful
and was chosen for his financial gain. He is morally bankrupt and
intellectually dishonest.


Quote:
- Assuming I modify a class by adding a field. How does schema
management
work with the above engines?

More incoherences.
I disagree that it is incoherent. His question equates to asking how the
type system would handle the addition of a new possible representation. And
the answer is: "Very well, thank you."


Quote:
How many steps are necessary to get the
database client and server to use my new field throughout my
application?

One or several.

Do I need to reorganize the database?

- How many steps are necessary to add a new class?

One.

What do I need to do exactly?

It depends on what DBMS you are using.

- How is class inheritance supported by the above engines?

They use different approaches.

Can I store
deep inheritance trees?

Another incoherent question.

- Bob was speaking of an "active" object database. Can Java (or C#)
code be run within the server?

Some of the above products can run Java, and the next release of SQL
Server can run C#.

Can this code be triggered from the
client?

Incoherent question. The code can be triggered in response of client
actions.

Is it possible to switch back and forth between client- and
server-side execution in closures?

Incoherent question.

- Can I run any of the above database engines in embedded mode?
(one thread shared between application and database engine)

It is monolithic mode. You can do that with Firebird SQL.

- What do I need to do to my classes, so they can be stored with the
above engines?
snip
- Assuming I want to use one of the two mainstream OO platforms, Java
or .NET, can I store any existing JDK / .NET class that come with the
system?

Incoherent questions, to store a clas classes does not make sense.

- How can I move or copy objects between database files (or client
sessions) with the above products?

Incoherent question. You are mixing logical and physical issues.

- Do the above products support any object database standards like
ODMG, JDO or ObjectSpaces?

Fortunately they don't support that nonsenses.

- Do the above products supply special database collections, so
collections do not need to be fully loaded into client memory to use
them? (LinkedList?, HashMap?)

Yes, they support tables or relations and you do not need to fully
load them into client memory.

Are server-side proxy collections supported?

Define server-side proxy collection?

- What kinds of dynamic fetch mechanisms are provided?

Define dynamic fetch mechanisms.

How can I load
certain fields of objects in one go? How can I navigate by loading
further fields?

More incoherences.

- Is it possible to unload objects from RAM that were modified by the
current transaction?

To unload by who?

- How does Rollback work?

As is described in the transaction processing theory books.

Can the state of instantiated objects be
restored and how do I do it?

More incoherences.

The above catalog of features can help very much, if you develop
object-oriented database applications.

All you write are nonsenses and incoherences.

I know that the four products that you listed are pretty bad at all of
them, Alfredo.

Perhaps they are bad, but they are a lot more powerful and
sophisticated than your product.

I would never call them "object databases" and none of
the vendors uses this term either.

Some of the vendors use the term Object-Relational DBMS.

I don't care about your personal
terminology.

You don't have a clue on terminology or data management.

Database engines that provide most or all of the above features are
commonly known as object databases.

Your incoherences are not features, and to call database to an engine
is another incoherence.

They are characterized by a very
tight language integration that minimizes development and refactoring
work. They excel at using very little ressources. They provide maximum
performance for navigational access to objects by minimizing the amount
of indirections needed, since no keys need to be matched.

More nonsenses.

I suppose this newsgroup was created for this product category.

I don't know for what this group was created, but you are trying to
use it to cheat the gullibles with meaningless pap.


Regards
Alfredo



Reply With Quote
  #42  
Old   
Corey Brown
 
Posts: n/a

Default Re: OOOS - 02-09-2004 , 11:22 AM







"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

Quote:
"Alfredo Novoa" <alfredo (AT) ncs (DOT) es> wrote in message
news:e4330f45.0402090456.14788ca5 (AT) posting (DOT) google.com...
"Carl Rosenberger" <carl (AT) db4o (DOT) com> wrote in message
news:<c06m43$7pb$06$1 (AT) news (DOT) t-online.com>...
Alfredo Novoa wrote:
Which other active OO database would you consider more
'advanced'?

DBMS, not database. More advanced OO DBMSs are Dataphor, FirstSQL and
even Oracle and DB2.

Interesting news.

- Does any of the above engines manage object identities within the
client?
For your understanding what I mean: If I access an object through
multiple
paths (queries, navigation) will I get back the same object every time?

Utterly incoherent question.

Not if one automatically assumes a network model and location based identity
as Carl does.
Carl is not assuming a network model. The question is quite valid. Obviously you
have no idea what application identity means.

Quote:

- What kind of object caching mechanism is used to provide this feature?

Again, only relevant to network model databases. Better databases than
network model have better caching options available.
Bullshit! This question has nothing to do with whether the DB is object
or relational. If you don't think that caching is an important aspect of
every database implementation, you are sadly mistaken.

Quote:

Weak references? How does the mechanism integrate with garbage
collection?

Why any references at all? Again, Carl implicitly assumes the user is stupid
enough to want to chase pointers.
Carl is assuming that the user is creating an application using an object
oriented language, which rely heavily on object navigation through
(pointer) references.

Quote:

- What kind of object-level locking is provided?

More nonsenses.

Again, Carl implicitly assumes a total lack of physical independence. Thus,
if one has a logical object one also has a physical resource that requires a
physical lock. What makes Carl worse than most is his ignorance is willful
and was chosen for his financial gain. He is morally bankrupt and
intellectually dishonest.
More bullshit. physical independence or not, if the system you're using
cannot guarantee consistency across transactions, you're screwed.

Carl provides a very good product for use in applications where an
object database makes sense. Get over it.

Quote:

- Assuming I modify a class by adding a field. How does schema
management
work with the above engines?

More incoherences.

I disagree that it is incoherent. His question equates to asking how the
type system would handle the addition of a new possible representation. And
the answer is: "Very well, thank you."
So you're saying that you're familiar enough with each of the products
mentioned that you can say, without a doubt, that each handles the situation
"very well"? Let's not confuse the theory of the model with the realities of
each implementation.

Quote:

How many steps are necessary to get the
database client and server to use my new field throughout my
application?

One or several.

Do I need to reorganize the database?

- How many steps are necessary to add a new class?

One.

What do I need to do exactly?

It depends on what DBMS you are using.

- How is class inheritance supported by the above engines?

They use different approaches.

Can I store
deep inheritance trees?

Another incoherent question.

- Bob was speaking of an "active" object database. Can Java (or C#)
code be run within the server?

Some of the above products can run Java, and the next release of SQL
Server can run C#.

Can this code be triggered from the
client?

Incoherent question. The code can be triggered in response of client
actions.

Is it possible to switch back and forth between client- and
server-side execution in closures?

Incoherent question.

- Can I run any of the above database engines in embedded mode?
(one thread shared between application and database engine)

It is monolithic mode. You can do that with Firebird SQL.

- What do I need to do to my classes, so they can be stored with the
above engines?
snip
- Assuming I want to use one of the two mainstream OO platforms, Java
or .NET, can I store any existing JDK / .NET class that come with the
system?

Incoherent questions, to store a clas classes does not make sense.

- How can I move or copy objects between database files (or client
sessions) with the above products?

Incoherent question. You are mixing logical and physical issues.

- Do the above products support any object database standards like
ODMG, JDO or ObjectSpaces?

Fortunately they don't support that nonsenses.

- Do the above products supply special database collections, so
collections do not need to be fully loaded into client memory to use
them? (LinkedList?, HashMap?)

Yes, they support tables or relations and you do not need to fully
load them into client memory.

Are server-side proxy collections supported?

Define server-side proxy collection?

- What kinds of dynamic fetch mechanisms are provided?

Define dynamic fetch mechanisms.

How can I load
certain fields of objects in one go? How can I navigate by loading
further fields?

More incoherences.

- Is it possible to unload objects from RAM that were modified by the
current transaction?

To unload by who?

- How does Rollback work?

As is described in the transaction processing theory books.

Can the state of instantiated objects be
restored and how do I do it?

More incoherences.

The above catalog of features can help very much, if you develop
object-oriented database applications.

All you write are nonsenses and incoherences.

I know that the four products that you listed are pretty bad at all of
them, Alfredo.

Perhaps they are bad, but they are a lot more powerful and
sophisticated than your product.

I would never call them "object databases" and none of
the vendors uses this term either.

Some of the vendors use the term Object-Relational DBMS.

I don't care about your personal
terminology.

You don't have a clue on terminology or data management.

Database engines that provide most or all of the above features are
commonly known as object databases.

Your incoherences are not features, and to call database to an engine
is another incoherence.

They are characterized by a very
tight language integration that minimizes development and refactoring
work. They excel at using very little ressources. They provide maximum
performance for navigational access to objects by minimizing the amount
of indirections needed, since no keys need to be matched.

More nonsenses.

I suppose this newsgroup was created for this product category.

I don't know for what this group was created, but you are trying to
use it to cheat the gullibles with meaningless pap.


Regards
Alfredo





Reply With Quote
  #43  
Old   
Alfredo Novoa
 
Posts: n/a

Default Re: OOOS - 02-09-2004 , 04:06 PM



"Bob Badour" <bbadour (AT) golden (DOT) net> wrote


Quote:
- Does any of the above engines manage object identities within the
client?
For your understanding what I mean: If I access an object through
multiple
paths (queries, navigation) will I get back the same object every time?

Utterly incoherent question.

Not if one automatically assumes a network model and location based identity
as Carl does.
I disagree, he said that a query is a path, he talked about navigation
in non navigational DBMSs, he asked about if he will get the same
object if he access the same object several times, and he said that
the question is the same as if a SQL DBMS manages logical pointers
within the client.

It sounds pretty incoherent to me.

Quote:
Weak references? How does the mechanism integrate with garbage
collection?

Why any references at all? Again, Carl implicitly assumes the user is stupid
enough to want to chase pointers.
He is asking about how something that does not exist integrate with
garbage collection in DBMSs that does not generate nor collect
garbage.

Quote:
- Assuming I modify a class by adding a field. How does schema
management
work with the above engines?

More incoherences.

I disagree that it is incoherent. His question equates to asking how the
type system would handle the addition of a new possible representation. And
the answer is: "Very well, thank you."
It is a possible condescending interpretation, but I still don't see a
lot of sense on what he asked.

If you order the DBMS to add a new component to a possible
representation then the DBMS will work adding a new component to the
possible representation.

What a stupid question!


Regards
Alfredo


Reply With Quote
  #44  
Old   
Carl Rosenberger
 
Posts: n/a

Default Re: OOOS - 02-09-2004 , 04:24 PM



Alfredo Novoa wrote:

Quote:
Utterly incoherent question.
[...]

Quote:
Incoherent question.
[...]

Quote:
More nonsenses.
[...]

Quote:
More incoherences.
[...]

Quote:
Incoherent question.


You sound like HAL in Kubricks 2001 Odyssey after his main
memory chips were removed.


Why do you invest so much time in this newsgroup?
What is your goal?
Don't you have anything else you can do with your life?


Good bye.
Carl




Reply With Quote
  #45  
Old   
Alfredo Novoa
 
Posts: n/a

Default Re: OOOS - 02-09-2004 , 05:23 PM



"Bob Nemec" <bobn (AT) rogers (DOT) com> wrote

Quote:
Alfredo,
All the points that Carl made that you answered "Utterly incoherent
question" to are valid.

Consistent object identity
It does apply only to network databases.

Quote:
, dynamic locus of control,
0 matches with Google.

Quote:
solid schema
management
Do you mean that model management is not solid with SQL DBMSs?

Quote:
, complex model support
Do you mean that SQL DBMSs does not support complex models?

Quote:
, incremental object faulting
A mere cache management implementation detail.

Quote:
A few examples...
If I navigate to a portfolios by way of a category index,
If you navigate you are using a very primitive and inconvenient
approach.

Quote:
like 'a -> pooled
fund>acme>portfolio object', vs. a link from a financial instrument 'b -
instrument>holding>portfolio object', I would expect that 'a' and 'b' would
be the exact same object, not two instances of a portfolio that reference
the same data.
If you use a non navigational DBMS you don't have to worry about that.

Quote:
I'd like to be able to move where the code executes between the client and
the server at will, without having to modify either code base.
:-?

Quote:
If I add an attribute the database should provide tools to make that change
painless.
It is trivial with any SQL DBMS.

Quote:
So, if I now need a #contract instance variable to the Portfolio
class, each instance of Portfolio should have the #contact variable added
and initialized correctly.
It is trivial to add a new attribute to a table, and to set what
initial values you want.

Quote:
I need to be incremental in how much of an object I fault from to the
client. So, when listing all the 'Pooled Funds', I only want the #name of
each fund for the list. But, when I select I fund, I want the full object
faulted.
SQL DBMSs are a lot better than network DBMSs for that.

Quote:
Schema changes: we built tools that use the solid GemStone classes to manage
our model.
With a SQL DBMS you don't need to build anything.

Quote:
Application refactoring is fundamental to our development
process, so we change things all the time. GemStone is not a limitation to
that development philosophy.
Network DBMSs are a limitation in many many ways.

Quote:
All of these would be non-trivial with something like Oracle & DB2 (been
there).
Most of these only apply to primitive DBMSs.


Regards
Alfredo


Reply With Quote
  #46  
Old   
Alfredo Novoa
 
Posts: n/a

Default Re: OOOS - 02-09-2004 , 05:26 PM



"Corey Brown" <corey (AT) spectrumsoftware (DOT) net> wrote


Quote:
Bullshit! object identity is extremely important when implementing an
object oriented system.
The Relational Model does not allow logical pointers.


Quote:
Alfredo, all of the items that Carl has listed here are legitimate issues surrounding
the development of applications with object databases. None of what he has
written is "nonsense".
It seems you are as ignorant as Carl.


Regards
Alfredo


Reply With Quote
  #47  
Old   
Bob Badour
 
Posts: n/a

Default Re: OOOS - 02-09-2004 , 05:47 PM



"Alfredo Novoa" <alfredo (AT) ncs (DOT) es> wrote

Quote:
"Corey Brown" <corey (AT) spectrumsoftware (DOT) net> wrote


Bullshit! object identity is extremely important when implementing
an
object oriented system.

The Relational Model does not allow logical pointers.
Identity is important for any variable, which is why logical identity is a
fundamental requirement for data management.

Only an ignorant idiot like Corey or Carl would assume identity necessarily
depends on physical location.


Quote:
Alfredo, all of the items that Carl has listed here are legitimate
issues surrounding
the development of applications with object databases. None of what
he has
written is "nonsense".

It seems you are as ignorant as Carl.
Indeed, he is.




Reply With Quote
  #48  
Old   
Alfredo Novoa
 
Posts: n/a

Default Re: OOOS - 02-09-2004 , 06:06 PM



"Corey Brown" <corey (AT) spectrumsoftware (DOT) net> wrote

Quote:
Carl is not assuming a network model. The question is quite valid. Obviously you
have no idea what application identity means.
Carl talked about object identity.

Object identity = pointer to an object.

Quote:
Bullshit! This question has nothing to do with whether the DB is object
or relational. If you don't think that caching is an important aspect of
every database implementation, you are sadly mistaken.
Caching is important in all disk based DBMSs, but caching issues are
rather different in network and relational DBMSs.


Quote:
Why any references at all? Again, Carl implicitly assumes the user is stupid
enough to want to chase pointers.

Carl is assuming that the user is creating an application using an object
oriented language, which rely heavily on object navigation through
(pointer) references.
Applications are for presentation, and DBMSs for data management. Carl
is talking about having pointers in database.

BTW pointers are one of the weakest points of OO languages.

Quote:
Carl provides a very good product for use in applications where an
object database makes sense. Get over it.
Laughable. You are as ignorant as him


Regards
Alfredo


Reply With Quote
  #49  
Old   
Bob Nemec
 
Posts: n/a

Default Re: OOOS - 02-09-2004 , 06:18 PM



"Alfredo Novoa" <alfredo (AT) ncs (DOT) es> wrote

Quote:
"Corey Brown" <corey (AT) spectrumsoftware (DOT) net> wrote


Bullshit! object identity is extremely important when implementing
an
object oriented system.

The Relational Model does not allow logical pointers.
But the client application needs to build objects from the relational data.
Making sure you don't have duplicate instances is critical to an OO app.

Now, if you're not using objects in your applications, that's fine too. But
then why spend time on comp.database.object ?

Quote:
Alfredo, all of the items that Carl has listed here are legitimate
issues surrounding
the development of applications with object databases. None of what
he has
written is "nonsense".

It seems you are as ignorant as Carl.
Can we give this 'ignorant' thing a rest? Everyone is ignorant of
something.
Insulting people adds nothing of value.

--
Bob Nemec
'93 FJ1200




Reply With Quote
  #50  
Old   
Alfredo Novoa
 
Posts: n/a

Default Re: OOOS - 02-10-2004 , 05:14 AM



"Bob Nemec" <bobn (AT) rogers (DOT) com> wrote


Quote:
Bullshit! object identity is extremely important when implementing
an
object oriented system.

The Relational Model does not allow logical pointers.

But the client application needs to build objects from the relational data.
Making sure you don't have duplicate instances is critical to an OO app.
The application needs to present the data. What you said does not have
sense unless you are trying to map classes to tables what is a big
nonsense.

Quote:
Now, if you're not using objects in your applications, that's fine too. But
then why spend time on comp.database.object ?
I use objects in my applications all the time, and none of what Carl
said has sense if you use a relational DBMS or a SQL DBMS that
supports OO.

Quote:
It seems you are as ignorant as Carl.

Can we give this 'ignorant' thing a rest? Everyone is ignorant of
something.
They are ignorant about databases, and this is a databases group.


Regards
Alfredo


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.