Fwd: Re: [Glorp-development] Partial loading of objects

X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 14 Dec 2006 22:27:11 -0500
To: "Mark Plas" <[hidden email]>,
        <[hidden email]>
From: Alan Knight <[hidden email]>
X-magma-MailScanner-Information: Magma Mailscanner Service
X-magma-MailScanner: Clean
X-Spam-Status:
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam Filtering performed by sourceforge.net.
        See http://spamassassin.org/tag/ for more details.
        Report problems to
         http://sf.net/tracker/?func=add&group_id=1&atid=200001
        1.0 FORGED_RCVD_HELO       Received: contains a forged HELO
        0.2 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date
        0.2 HTML_TEXT_AFTER_BODY BODY: HTML contains text after BODY close tag
        0.0 HTML_MESSAGE           BODY: HTML included in message
        0.5 HTML_20_30             BODY: Message is 20% to 30% HTML
Subject: Re: [Glorp-development] Partial loading of objects
X-BeenThere: [hidden email]
X-Mailman-Version: 2.1.8
List-Id: <glorp-development.lists.sourceforge.net>
List-Unsubscribe: < https://lists.sourceforge.net/lists/listinfo/glorp-development >,
         <[hidden email] >
List-Archive: < http://sourceforge.net/mailarchive/forum.php?forum=glorp-development >
List-Post: <[hidden email]>
List-Help: <[hidden email] >
List-Subscribe: < https://lists.sourceforge.net/lists/listinfo/glorp-development >,
         <[hidden email] >
Sender: [hidden email]
X-pstn-levels:     (S:99.90000/99.90000 R:95.9108 P:95.9108 M:97.0282 C:98.6951 )

Yes, that all sounds reasonable. You certainly wouldn't want to be joining in things you could tell in advance weren't needed. And there might need to be scope for letting people specify how to do particular queries. That is, whether to do an outer join, to do multiple queries, or to defer reading part of the data.

At 05:46 AM 12/14/2006, Mark Plas wrote:

Hi Alan,
 
For the first part (the performance part), I could just query the individual fields, but as you say then I wouldn’t have my domainobject logic around, which sounds less interesting.
 
Concerning the 2^nd part: To know which class something is, I guess the easiest thing would be to add a specific field containing that information. You’d also need to know how to join the different tables together. Giving them the same primary key looks like a good choice.
 
To avoid the need for the ‘partial loading proxies’ outer-joining all the tables is an interesting approach, even though performance wise this may not always be wanted. Having the option not to do it could be needed.
 
You could possibly avoid outer-joining up until the level of the class hierarchy of the objects you’re retrieving:
 
Example 1:
 
Session readManyOf: ClassA where: [:eachA | eachA a = 5]
 
Would result into (oracle syntax):
 
Select …
From ClassA, ClassB, ClassC
Where
            ClassA.a = 5 and
            ClassA.primaryKey = ClassB.primaryKey(+) and
            ClassA.primaryKey = ClassC.primaryKey(+)
 
à You need to do the outer join because the result could be ClassB or ClassC (classA is an abstract class in my example)
 
Example 2:
 
Session readManyOf: ClassB where: [:eachB | eachB a = 5]
 
Would result into (oracle syntax):
 
Select …
From ClassA, ClassB
Where
            ClassA.a = 5 and
            ClassA.primaryKey = ClassB.primaryKey
 
à here the outer join between ClassA and ClassB isn’t needed because you’re selecting ClassB instances and ClassB doesn’t have any subclasses. Additionally, since I’m retrieving ClassB The join with ClassC isn’t needed anymore.
 
Mark
 

---

From: [hidden email] [ [hidden email]] On Behalf Of Alan Knight
Sent: woensdag 13 december 2006 19:42
To: Mark Plas; [hidden email]
Subject: Re: [Glorp-development] Partial loading of objects
 
OK. I note that you can get partial loading, just without the objects, or the automatic loading of the rest :-)

That is, you can do things like
    query retrieve: #id.
    query retrieve: #firstName.
    query retrieve: #lastName.
and you'll get back an array of three items instead of the object. You can also do
   query retrieve: [:each | each address street].
to get back things from multiple objects. This also means you don't get objects in the cache, or registered in the unit of work, which is sometimes useful for performance.

The inheritance scheme could be an interesting usage. One issue, however, is how you know what class something is. Do you require people to have a field indicating that in the A table? Or in a scheme like that, is the mere presence of a B row with the same primary key as the A row an indicator that the object with that primary key is an instance of B. If so, then you don't know which table to get when they touch the proxy.

My inclination, when fetching objects with that kind of structure, would be to outer join in all the possible tables and just look for which ones have data. That minimizes the number of queries. But other performance considerations might make you want to do it another way.

At 11:30 AM 12/13/2006, Mark Plas wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary="----_=_NextPart_001_01C71ED4.13B1D00E"

Hi Alan,
 
I’m talking about having simple fields that I don’t want to fetch right away, but I also have another use for it.
 
There are two reasons why I would want partial loading:
The first one is performance.
The 2^nd one (and this is the real reason :^) ) is because I think this mechanism is useful to allow for a third way of mapping a class hierarchy on a ‘hierarchy’ of tables. Glorp currently supports two ways for this kind of mapping: one separate table for each concrete class or one table that contains the union of all fields of each concrete subclass. I’d like to have the option where I can have a database structure that mimics the class hierarchy. i.e. I want to have a separate table for each class in the superclass hierarchy.
 
In such a setup, suppose I have these classes:
 
ClassA with a field called ‘a’. This is an abstract class.
ClassB which subclasses from ClassA and adds a field ‘B’
ClassC which also subclasses from ClassA and adds a field ‘C’
 
I would have corresponding tables for these classes (tables called: ClassA(a), ClassB(b), ClassC(c)).
 
When I then issue this query:
 
Session retrieveManyOf: ClassA where: …
 
I want as a result instances of ClassB and ClassC, but only with the instance variables of ‘ClassA’ filled in on them. i.e.: only the field ‘a’ filled in, because that’s the only field that’s available on the ClassA table. I wouldn’t want Glorp to start fetching all the specific fields for each instance by loading them from the ClassB and ClassC tables. Instead I would like Glorp to put a ‘partial object loading’ proxy into those variables so that when they get accesses, it would load field ‘a’ from the ClassA table, or field ‘b’ from the ClassB table, depending on the receiver.
 
So, actually, the question ‘does glorp support partial loading of objects’ was some kind of a way for me to come to this ‘class hierarchy mapping’ thing.
 
It would be a nice extension to Glorp I believe. I’m interested to know about how complex it would be to extend it with this kind of functionality ? Have you already given this some thought ?
 
Thanks,
Mark
 
 

---

From: Alan Knight [ [hidden email] ]
Sent: woensdag 13 december 2006 16:19
To: Mark Plas; [hidden email]
Subject: Re: [Glorp-development] Partial loading of objects
 
If the other fields are relationships to other objects, then they are proxied by default, although the fetching of the proxies only gets the immediately-referred to object. However, I assume you're talking about the case where you have simple fields, and want to ftch only some of them. You can also proxy a direct mapping, but there isn't a mechanism right now to make firing one of those proxies also fire a number of others, or to read in the object altogether.

I think you could fake that up using an ad hoc proxy, which runs an arbitrary block, relatively easily, but better support would be desirable. Again, it wouldn't be too difficult to implement, just a matter of actually doing it. I think you could fairly easily make it use proxies that triggered a refresh on the whole object, rather than doing the normal proxy thing. There's a possible issue that you might not want to re-read fields that had already been read and were being modified. There might also need to be a bit of work on making sure objects were properly re-registered when that happened to detect changes (I'm not sure it's necessary, just thinking out loud).

At 04:51 AM 12/13/2006, Mark Plas wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary="----_=_NextPart_001_01C71E9C.48B2E104"

Hi,
 
This mail is part of a set of glorp questions I have (see some other mails I've sent recently).
 
The question I would like to address here is:
 
Is it possible to do ‘partial’ loading of objects. What I mean is: I have an object with 100 fields. Only 10 of them are important in some application. I would like to be able to read in this object with only 10 fields filled in, and the other 90 replaced with proxies that would fetch the rest of the fields as soon as one of those fields got accessed.
 
Does Glorp support a mechanism to do this ?
 
Thanks,
Mark
 
 
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Glorp-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/glorp-development

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Glorp-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/glorp-development

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Glorp-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/glorp-development