Destroying related objects doubt ... basic oop question

Ruby
1

::Destroying related objects doubt

One thing that is confusing me is regarding the lifecycle of the
associated objects and the related data in the database. Suppose we have
an example of object composition and in this case if I destroy de parent
object then the children objects will be destroyed too.

Well, the confusion I’m doing is related to the semantics of the word
‘destroy’. In my understanding when I say ‘destroy’ an object, it means
I will unset it, but I will not ‘delete’ the related data in the
database.

ex.: let’s say we have objects House and Rooms, the relationship between
them is composition, so House is responsible for creating new Rooms. If
I destroy the instance of House, all instances of Rooms will be
destroyed as well, but it doesn’t mean I have to ‘delete’ them from the
database, right? … sounds like a silly question, but …

thanks in advance, sohdubom

2

ex.: let’s say we have objects House and Rooms, the relationship between
them is composition, so House is responsible for creating new Rooms. If
I destroy the instance of House, all instances of Rooms will be
destroyed as well, but it doesn’t mean I have to ‘delete’ them from the
database, right? … sounds like a silly question, but …

So what’s your question? You’re the city planning
departement/programmer. If
you call House.destroy
or whatever your database API might be, it’ll vanish from the db, if
not,
well,
then not…

Greetz

3

Soh D. wrote:

ex.: let’s say we have objects House and Rooms, the relationship between
them is composition, so House is responsible for creating new Rooms. If
I destroy the instance of House, all instances of Rooms will be
destroyed as well,

Really?

class House
def initialize(room)
@room = room
end
end

class Room
def show
puts “I’m a room.”
end
end

r = Room.new
h = House.new®
h = nil

r.show

–output:–
I’m a room.

4

On Tue, Aug 11, 2009 at 13:57, 7stud – [email protected] wrote:

@room = room
h = House.new(r)
h = nil

r.show

–output:–
I’m a room.

Posted via http://www.ruby-forum.com/.

That’s not composition. In a composition relationship the House class is
responsible for managing the Room class and you can’t pass in a Room to
the
House constructor
-Mario.

5

Actually after some research I figured out that:

  1. The rules set for the particular app will say if the relationship is
    Composition, Aggregation or etc

  2. Since i decided that it’s a Composition, so when I delete House, its
    Rooms should also be deleted, and the deletion/destroying is regarding
    to the database record, not the object instance because the object
    instance will be vanished anyways after the script is executed.(in
    composition, aggregation, association, etc)

Although we deal with object instances, Object Relationships are related
to what happens to the records in the database for a particular
operation, eg deleting the parent object/model. The instances will,
sooner or later, be vanished, but the database records will or will not
depending on the relationship.

@ ‘7stud’ : setting NIL to an object doesn’t delete it, nor destroy it.
I remember that in PHP I can unset(obj) that is different from NIL or
NULL, but even though I’m not sure it will force GC

6

Yet another reason for steering well clear of object-relational mappers.

Stick with a proper relational database and everyone knows what’s going
on, since we all worked that out 30 years ago.

def sarcasm
and why don’t we just write all programs in assembler again? we
figured
that out
even before relational databases! man, I wished we were back in the
good
ole days…
end

The instances will,

sooner or later, be vanished, but the database records will or will not
depending on the relationship.

but you still don’t want any dangling references. I guess you’d like the
app
to run longer
than 5 minutes, so you want to get rid of stuff you don’t need or else
it’ll
just pile up until
the RAM is loaded to the brink :slight_smile:

@ ‘7stud’ : setting NIL to an object doesn’t delete it, nor destroy it.

I remember that in PHP I can unset(obj) that is different from NIL or
NULL, but even though I’m not sure it will force GC

but if the variable you set to nil was the last reference to the object,
GC
will sooner or later
get rid of it.

Greetz!

7

Mike S. wrote:

Yet another reason for steering well clear of object-relational mappers.

Stick with a proper relational database and everyone knows what’s going
on, since we all worked that out 30 years ago.

Actually, it wasn’t worked out 30 years ago (I was there)… The OP is
correct in stating that the relationship for the type of composition
must be stated in the actual design/problem domain.

Within UML(both 1 and 2), we represent aggregation of a resource with
both a shared symbol and a containment symbol to represent the
differences in ownership and what should happen if the container
vanishes

The same rules are specified in the database model through constraints…
no difference…

Ironically, the OPs question was very well phrased and had nothing at
all to do with OR mappers…

ilan “defender of the OR mappers!” berci

8

Fabian S. wrote:

why don’t we just write all programs in assembler again?
Greetz!

It was shown (30 years ago) that assembler is noticeably less productive
than 3GLs
and therefore should only be used where ultimate cpu control is
essential. By contrast no-one has justified bringing entity-relationship
models into object oriented programs. It’s just a whim of some over
zealous OO geeks.

I wished we were back in the good ole days…

There’s nothing stopping you…

Simplez

9

I think the reality is more complex than either of the two positions
espoused here.

OR mapping does play a part in this discussion. But the problem isn’t
OO, it’s the opposite.
When we use the Active Record design pattern we’re saying that the DB
schema comes first,
and the class model is a second class thing. The productivity gains of
Rails shows that, for many
applications, this approach is powerful. The weaknesses of this
approach emerge when things start
getting bigger, and when it’s an application product line, and not a
single application, that is vital.

Perhaps the most intelligent OO book of the last decade is Eric Evan’s
Domain Driven Design.
He describes a compelling approach to building a domain model of
classes that accurately models
a sophisticated business, and can support a product line of related
applications. In this approach
it’s the object model, not the DB schema, that is king. This approach
can lead to treating the DB
as merely the persistent representation of the object model. Evan’s
approach explicitly distinguishes
entity objects from value objects and encourages clear ownership
policies.

There is a great Rails book, Enterprise Rails, that does a good job of
bridging these approaches with
some of the earlier DB-centric development practices.

Peter

10

It was shown (30 years ago) that assembler is noticeably less productive
than 3GLs
and therefore should only be used where ultimate cpu control is
essential.

well, i’m faster making three dumb classes with an orm and calling 3
class
methods with 2 parameters
than setting up and maintaining a database myself and figuring out every
single SQL statement myself
and handling the returned raw data on my own.

so what’s your point? first you say we shouldn’t use orm, it gives us
too
litte control, now you
reject control in favor of effectiveness… :slight_smile:

also, orm offer great features besides mapping objects to database
entities,
e.g. they help
preventing sql injection and provide tested features for input
validation.

Peter: great analysis. I have to agree. one surely has to consider what
the
application one works
on needs. rejecting either approach without even considering is not a
good
choice. but i certainly
think that most plain vanilla web apps (for which i think the orm issue
is
most popular) do very
well with it. the problems that using an orm brings IMHO only arise when
your application reaches
a certain complexity at which level the lost control needs to be
reclaimed
to ensure performance,
maintainability, functionality etc., or does anyone have different
experiences?

Greetz!

11

Fabian S. wrote:

you say we shouldn’t use orm, it gives us too little control

My point was ORMs mean you have to struggle understanding a new
‘language’. Most (not all) developers will appreciate how relational
databases work and would know how to adjust referential integrity
behaviours. This thread started with:

One thing that is confusing me is regarding the lifecycle of the
associated objects and the related data in the database.

I just would suggest to people: don’t use Activerecord etc unless you
have a deep urge to do so. It’s not the ‘correct’ way to do things; just
one possible approach. Whatever arguments you make for controlling data
from your Ruby program can be countered by at least as many that say you
should leave that to the database.

12

On Thu, Aug 13, 2009 at 12:26 AM, Mike S.[email protected]
wrote:

I just would suggest to people: don’t use Activerecord etc unless you
have a deep urge to do so. It’s not the ‘correct’ way to do things; just
one possible approach. Whatever arguments you make for controlling data
from your Ruby program can be countered by at least as many that say you
should leave that to the database.

No, really, they can’t. Whether you use an ORM, or whether you use a
lower-level database API and have your Ruby program use SQL directly
(which is, after all, what your ORM is doing “behind the scenes”) the
data is stilling being controlled by the Ruby program.

13

Christopher D. wrote:

the data is still being controlled by the Ruby program.

That would mean anyone across the entire corporation is somehow going to
have to call your classes to manipulate the data. Believe me, that isn’t
going to happen.

If you’re Warner Brothers and you want to work out what DVDs you’ve sold
today in the South American Regions you aren’t going to use Ruby. It’s
going to be Oracle and related special products, and that’s what it’s
like everywhere. Once other people have access to the data then the OO
position is undermined.

Encapsulate private program data but leave shared business data to
databases.

My other concern is why build your own wrappers when relational
databases already have excellent wrappers built in (you won’t beat SQL)
and millions of man hours of optimisation code.

If you are not familiar with databases then by all means use an ORM but
I would have thought most developers would be better served by filling
in that knowledge gap at an early stage.

If you’re just writing a shopping cart or social networking forum etc
your data might be quite simple but if you moved say to monthly billing,
discounts, credit limits, then I think it starts to get like eating food
with chop sticks - entirely a dodgy idea.

14

Yet another reason for steering well clear of object-relational mappers.

Stick with a proper relational database and everyone knows what’s going
on, since we all worked that out 30 years ago.

15

On Thu, Aug 13, 2009 at 7:26 AM, Mike S.[email protected]
wrote:

Christopher D. wrote:

 the  data is still being controlled by the Ruby program.

That would mean anyone across the entire corporation is somehow going to
have to call your classes to manipulate the data.

No, it wouldn’t. Whether you use an ORM or not, anything that can
access the backing database can manipulate the data, and using an ORM
– even using its calls to handle things like associations – doesn’t
make the database inaccessible to other users.

Now, if you solely use application-level code to specify what are
logically constraints that apply to the data rather than the
particular use in your application, then, yes, your database is not
going to be set up in the best manner for other users. And yes,
certain opinionated ORMs (ActiveRecord used to be this way, though I
gather it has improved some) may work more easily with setups that are
less than ideal for other users. That’s not a fundamental problem with
ORM, so much as a reflection of the particular use-cases that shaped
the development of those particular ORM libraries.

If you’re Warner Brothers and you want to work out what DVDs you’ve sold
today in the South American Regions you aren’t going to use Ruby. It’s
going to be Oracle and related special products, and that’s what it’s
like everywhere.

Actually, using general purpose languages (including Ruby) to build
applications that access relational databases, like Oracle, is fairly
common. That’s why most general purpose languages have database
libraries, and why most OO general purpose languages have multiple
competing ORM libraries. If no one used these languages to access data
in their big databases, the libraries wouldn’t be so widespread.

Once other people have access to the data then the OOposition is undermined.

What “OO position”? How is it undermined?

Encapsulate private program data but leave shared business data to
databases.

If you are using an ORM (or even just a lower-level database API), you
are leaving the data to the database. If the data wasn’t being left to
the database, you wouldn’t need a database library, ORM or otherwise,
to access it.

My other concern is why build your own wrappers when relational
databases already have excellent wrappers built in (you won’t beat SQL)
and millions of man hours of optimisation code.

SQL is not, obviously, a wrapper around SQL. And, yes, you can
(easily) beat directly coding every database oriented task in SQL when
you are trying to build an application in a general purpose language
which accesses data held in a relational database that uses SQL, just
as you can do better than handcoding the HTML for every possible task
and result when writing a web application in a general purpose
language, even though HTML is an excellent language for communicating
to a web browser what you want it to present.

If you are not familiar with databases then by all means use an ORM but
I would have thought most developers would be better served by filling
in that knowledge gap at an early stage.

I actually know relational theory and SQL (not that the latter is a
very good implementation of the former, but that’s pretty far off
topic) much better than I know any particular ORM library; but for
most database tasks from a language like Ruby, I’d prefer to use an
ORM. Using an ORM isn’t an alternative to understanding databases in
general, though it is a way of abstracting the particular underlying
database.

If you’re just writing a shopping cart or social networking forum etc
your data might be quite simple but if you moved say to monthly billing,
discounts, credit limits, then I think it starts to get like eating food
with chop sticks - entirely a dodgy idea.

More complex tasks that are beyond the use cases which motivated the
design of an ORM are likely to require some custom SQL coding whether
or not you use an ORM; on the other hand, more complex systems benefit
the most, in general, from abstraction in the application level rather
than using pervasive low-level coding. If you understand the SQL, and
the ORM is extensible (which, given the nature of Ruby, is usually the
case with Ruby-based ORMs) it may be better to use the SQL knowledge
to extend the ORM (or at least the particular model classes involved
in the more involved tasks) than to try to directly code the SQL for
every task all over the application.

16

Mike S. wrote:

If you’re just writing a shopping cart or social networking forum etc
your data might be quite simple but if you moved say to monthly billing,
discounts, credit limits, then I think it starts to get like eating food
with chop sticks - entirely a dodgy idea.

I tried eating food without chopsticks once. Much worse that way. Don’t
recommend it at all. :stuck_out_tongue: