Shared read-only objects
20 views
Skip to first unread message
jtuchel
Jan 27, 2012, 2:55:04 AM1/27/12
to glorp...@googlegroups.com
Hi,
I know this question has been asked before, but it seems GLORP has no good solution for it (yet). So I thought I'd come up with it again ;-)
In a Seaside App I'd like to have a bunch of dozens objects that are mostly read-only and only need to be administered very rarely. Something like bic or zip codes etc. Objects used in GLORP sessions should be allowed to establish references to them without updating or (even worse) inserting into these tables.
So the base problems I see is that I'd like to avoid each Seaside Session to read all those dozens or hundreds of objects into their cache and undoMap, because there is no need to update them. No need to blow up each session that much.
Since what I understand from earlier discussions spread all over the web is that GLORP has no atomatic support for this, I was looking at options.
The first, naive idea would be to have a separate session that reads in all these read-only objects and stores them in some context like a Seaside Session or a Class variable or whatever. Just some place where everybody can read these objects from. Since it would be a separate session in which nobody ever commits anything, these objects would be unique and I could use them for Ajax components that allow searching.
BUT as soon as an application session would update an object with a reference to one of these read-only objects, it would issue an INSERT statement, because the referenced object is not in the read cache and therefor must be new from the perspective of the session. Somewhere in a group Alan suggested using #registerAsOld: for such objects, but that would need some pollution of my business code with GLORP logic. I'd like to avoid that.
So my second approach is this:
Since all I need to do is store the foreign key of that read-only object, I could also write code that explicitly gets the id of the read only object and store only that value in the respective instance variable of my session-object. And vice versa: if I display the session object, I get the referenced read-only object and display it. I could use some kind of converter for that. It gets the zip code from the session object and fetches the read-only object from my application context and displays soem sort of #displayString of the read-only City object. In a Drop-Down list for selection of cities I'd display real city objects and store only the new zip code in the business object.
This second approach might work and be less polluting than the first one. But still I have the feeling that GLORP should support something like cross-session-read-only objects.
What do others think?
Joachim
I know this question has been asked before, but it seems GLORP has no good solution for it (yet). So I thought I'd come up with it again ;-)
In a Seaside App I'd like to have a bunch of dozens objects that are mostly read-only and only need to be administered very rarely. Something like bic or zip codes etc. Objects used in GLORP sessions should be allowed to establish references to them without updating or (even worse) inserting into these tables.
So the base problems I see is that I'd like to avoid each Seaside Session to read all those dozens or hundreds of objects into their cache and undoMap, because there is no need to update them. No need to blow up each session that much.
Since what I understand from earlier discussions spread all over the web is that GLORP has no atomatic support for this, I was looking at options.
The first, naive idea would be to have a separate session that reads in all these read-only objects and stores them in some context like a Seaside Session or a Class variable or whatever. Just some place where everybody can read these objects from. Since it would be a separate session in which nobody ever commits anything, these objects would be unique and I could use them for Ajax components that allow searching.
BUT as soon as an application session would update an object with a reference to one of these read-only objects, it would issue an INSERT statement, because the referenced object is not in the read cache and therefor must be new from the perspective of the session. Somewhere in a group Alan suggested using #registerAsOld: for such objects, but that would need some pollution of my business code with GLORP logic. I'd like to avoid that.
So my second approach is this:
Since all I need to do is store the foreign key of that read-only object, I could also write code that explicitly gets the id of the read only object and store only that value in the respective instance variable of my session-object. And vice versa: if I display the session object, I get the referenced read-only object and display it. I could use some kind of converter for that. It gets the zip code from the session object and fetches the read-only object from my application context and displays soem sort of #displayString of the read-only City object. In a Drop-Down list for selection of cities I'd display real city objects and store only the new zip code in the business object.
This second approach might work and be less polluting than the first one. But still I have the feeling that GLORP should support something like cross-session-read-only objects.
What do others think?
Joachim
Diogenes Moreira
Jan 27, 2012, 7:55:46 AM1/27/12
to glorp...@googlegroups.com
Hi!
When I need do something like it, I used #realObject method for obteing a transient object to store in the seaside session in a session with NoCachePolicy. Then in the persistence time replace the transient object for persistent objects.
Best
D.
Pd: I'm sorry for my english
El ene 27, 2012 4:55 a.m., "jtuchel" <jtu...@objektfabrik.de> escribió:
jtuchel
Jan 27, 2012, 10:26:05 AM1/27/12
to glorp...@googlegroups.com
Diogenes,
I don't think that really is a solution, unless I do a lot of handcoding and registerAsOld: and stuff. The session that wants to persist an onject with a reference to that readonly object would try an INSERT otherwise, because the object seems to be new as it is not in the session's cache... I want to avoid mixing too much persistency code into my business code.
...Or maybe I don't really understand what you suggest.
Joachim
I don't think that really is a solution, unless I do a lot of handcoding and registerAsOld: and stuff. The session that wants to persist an onject with a reference to that readonly object would try an INSERT otherwise, because the object seems to be new as it is not in the session's cache... I want to avoid mixing too much persistency code into my business code.
...Or maybe I don't really understand what you suggest.
Joachim
Alan Knight
Jan 27, 2012, 12:00:42 PM1/27/12
to glorp...@googlegroups.com
Here's a thought, although
I haven't actually tried this myself.
Read the shared objects in a separate session. Have them available through a registry that doesn't even use Glorp API's so that it's less confusing. So, e.g. Registry countryNamed: 'CA'. Mark them immutable, just so somebody doesn't do anything stupid.
In the individual sessions, don't even map those objects. Rather, have direct mappings
Person>> country
Define type converters for these types of objects that convert them by looking them up or saving primary key. Then they get treated like e.g. booleans (sort of, booleans don't have primary keys). But on the way into the database they're converted to numbers. On the way out they're looked up in the registry.
Glorp doesn't know that these are foreign keys,but I think that shouldn't be an issue because these objects already exist in the database and you should never run into ordering problems. You might need to be slightly careful in your interface for actually editing the read-only objects, but other than that it seems like this would work ok.
Read the shared objects in a separate session. Have them available through a registry that doesn't even use Glorp API's so that it's less confusing. So, e.g. Registry countryNamed: 'CA'. Mark them immutable, just so somebody doesn't do anything stupid.
In the individual sessions, don't even map those objects. Rather, have direct mappings
Person>> country
Define type converters for these types of objects that convert them by looking them up or saving primary key. Then they get treated like e.g. booleans (sort of, booleans don't have primary keys). But on the way into the database they're converted to numbers. On the way out they're looked up in the registry.
Glorp doesn't know that these are foreign keys,but I think that shouldn't be an issue because these objects already exist in the database and you should never run into ordering problems. You might need to be slightly careful in your interface for actually editing the read-only objects, but other than that it seems like this would work ok.
jtuchel
27 January, 2012 10:26 AM
--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To view this discussion on the web visit https://groups.google.com/d/msg/glorp-group/-/tDC9WATjQ1QJ.
To post to this group, send email to glorp...@googlegroups.com.
To unsubscribe from this group, send email to glorp-group...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en.
Diogenes Moreira
27 January, 2012 7:55 AM
Hi!
When I need do something like it, I used #realObject method for obteing a transient object to store in the seaside session in a session with NoCachePolicy. Then in the persistence time replace the transient object for persistent objects.
Best
D.Pd: I'm sorry for my english
--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To post to this group, send email to glorp...@googlegroups.com.
To unsubscribe from this group, send email to glorp-group...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en.
jtuchel
Jan 31, 2012, 3:40:59 AM1/31/12
to glorp...@googlegroups.com, kni...@acm.org
Hi Alan,
thanks for the suggestion I was on the same track and I think I'll try that approach. AFAIK, I can even close that extra session after reading my read-only objects and keep them detached...
Joachim
Reply all
Reply to author
Forward
0 new messages