Smalltalk › Instantiations

Question on GLORP and TransferObjects and DAO pattern comparison

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

a62754

Question on GLORP and TransferObjects and DAO pattern comparison

Question 1:

In the GLORP documentation :: Detached Obejcts section

http://www.instantiations.com/docs/86/db/dbglp07.html

its noted that the class object that gets created should not be stored and returned for future use after closing the connection.

My question is: for me this is the transfer object that holds data.

I created glorp mapping, i created my object class to hold data coming from database. my object got instantiated and data got filled in by glorp. How do i use this object in my application - do i create a copy and return that? If yes, there would be two transfer objects in my hierarchy.

Question/Discussion 2:

I would like to get thoughts on how GLORP fits the DAO pattern

http://www.oracle.com/technetwork/java/dataaccessobject-138824.html

My understanding is that the Person class (as mentioned in glorp documentation) is the transfer object. The class that i'll create to do a database login, get data and close connection would be my DAO object. MyPersonDAO object would return the Person object to my application for use. Inside it'll be using GlorpSession and MyPersonGlorpDescriptor to create the Person object.

Correct?

Question 3:

Frameworks like hibernate/etc have the ability to generate the DAO layer code. Do we have a similar ability in Glorp or is it in the works?

Thanks

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.

jtuchel

Re: Question on GLORP and TransferObjects and DAO pattern comparison

Hi anonymous user,

Am Freitag, 8. November 2013 06:04:18 UTC+1 schrieb a62754:

Hi

Question 1:
In the GLORP documentation :: Detached Obejcts section
http://www.instantiations.com/docs/86/db/dbglp07.html
its noted that the class object that gets created should not be stored and returned for future use after closing the connection.

Detached objects are full of pitfalls and the guy who once wrote the document on which Instantiations' documentation is based didn't understand all of them.

So what a detached object is is an object that was loaded in a Glorp Session that gets closed beneath it. So nobody keeps track of changes to that object or knows if any object loaded in another session is the same as this detached object.

Examples: you load Employee Sam in one session and close that session.

(1)Another session loads a Department which Sam is part of. The session will load its own copy of Sam (if you touch its proxy in the employees collection) and treat it as an existing object. You won't be using the detached object in this scenario

(2) in another Session you create a department and add (the detached) Sam is an employee to it. The new session will INSERT a new copy of Sam, because it has no chance to know Sam came from the DB. This is really a dangerous problem.

The only way to get around this problem is to use registerAsOld: in the new Session to make things work. But then you need to do your own accounting about which objects are registered in session and which aren't. Don't even try to do that, you'll shoot yourself into both feet.

I can think of a few situations in which it would be useful to load objects from the DB and use them, but keep Glorp from trying to insert them in other sessions. But there is no built-in support for this in Glorp. You'd have to make sure your pointers from your objects that are handled in a Glorp session do not map the target object directly but in some form of Proxy that saves the foreign key but does not load/save the associated object. I've been playing with this, but have not come to a satisfying solution.

My question is: for me this is the transfer object that holds data.
I created glorp mapping, i created my object class to hold data coming from database. my object got instantiated and data got filled in by glorp. How do i use this object in my application - do i create a copy and return that? If yes, there would be two transfer objects in my hierarchy.

I have no idea what you mean with a transfer object. You usually have multiple copies of an object around. Each session that read an object has at least its own working copy that it presents to you, and it will keep a copy of the object as it was loaded from the DB. But this one is not of interest to you and you usually don't see it. Maybe that is what you mean with a Transfer object. But all of this is transparent to you as a user of the session object.

Always keep in mind: Sam from Session A ~= Sam from Session B (they are separate instances).

Another important consequence: With an O/R Mapper, operations like #allInstances make no sense.

So to answer some of your questions:

You don't care about which object to use. You do a #readManyOf: and get the objects that you use just as you would use any Smalltalk object that you created using its #new method and attribute setters. There is no need to copy anything, that is done by Glorp and hidden from you.

Question/Discussion 2:
I would like to get thoughts on how GLORP fits the DAO pattern
http://www.oracle.com/technetwork/java/dataaccessobject-138824.html

My understanding is that the Person class (as mentioned in glorp documentation) is the transfer object. The class that i'll create to do a database login, get data and close connection would be my DAO object. MyPersonDAO object would return the Person object to my application for use. Inside it'll be using GlorpSession and MyPersonGlorpDescriptor to create the Person object.
Correct?

To be honest; I don't care about the DAO pattern and neither have time nor energy to read the document you link to. So if anybody feels like discussing more on this topic, please do ;-)

Question 3:
Frameworks like hibernate/etc have the ability to generate the DAO layer code. Do we have a similar ability in Glorp or is it in the works?

Hibernate has to fight static typing and early binding and therefor has to compile individual code for each persistent class.

In Glorp you don't have to create any code like that. All you have to do is to write the mapping code in your DescriptorSystem subclass. The rest is handled by Glorp. It will not create any artifacts like hibernate does.

What kind of code do you have in mind here?

Are you talking of generating the mapping code from an existing Database Schema? I know Cincom has something like that in the works, and Instantiations has plans to integrate this to VA in one of the next releases of VAST.

HTH

Joachim