integratis-cvs Mailing List for Integratis Web Development Framework
Brought to you by:
dorlov
Menu
▾
▴
integratis-cvs — Integratis code base maintenance
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
|---|
|
From: Dmitry O. <do...@ba...> - 2002-12-06 15:58:55
|
I have come across a case where our caching strategies don't do quite what I want. What I want is a pool object with a "since last reference" cache policy that has some child objects. These child objects should stick around - I don't want to check whether they've been dumped from the cache and pull them out of the database again every time I access them, so, ideally, a "forever" cache policy would work best for them. If I set a "Forever" policy on these child objects, the parent object will never get destroyed, because it has children. If I give the child objects a "since last reference" cache policy, then, regardless of that policy's duration, they will be destroyed before the parent, which means that I have to go back to checking for them each time I access them. Catch-22. I have a work-around: create a parallel object, give that object a "forever with inheritance" cache policy, link to it from the main object, and destroy it from the main objects "destroy" method. I also have a proposed solution: add an "X" cache policy flag, which would stand for "with extreme prejudice". It is a signal to DeathRow to destroy the object together with its children when the time comes. This would allow us to have a parent object with a "since last reference, X" policy, children with a "forever" policy, and they all get destroyed in one go when the parent's time comes. We could also change DeathRow to act "with extreme prejudice" by default, but I think there might be cases where that's not what one would want to happen. Can anyone think of examples? -Dmitry |
|
From: Brian R. <br...@ba...> - 2002-11-20 16:06:24
|
Good point about using the integratis list. :) I agree with the ORMap.in-db ($class @keys) variant... that should be fine. I probably won't implement that variant right away, but I'll put a todo in ORMap.tw. I'm not sure about find-class living in Server. I know I said that the problem I had was with a "freshly started server", but I actually ran into it with a simple twine test script not running against a server. I still think a client-server-mode neutral module would be a better place, but you're right that Server is a better place for it than Root. I'll put it there for now. As for reload-class, I think that it would be fine for it to only reload the scripting languages and ignore any .so's. If someone is compiling something to be used in a class, they should expect to have to restart the server anyway. Here's a crazy thought... I don't remember if there's a way to unload a .so and unregister its symbols... but if there is, maybe we could do that. Other than the issue of locking out threads trying to use the class (which is a problem for scripting languages too), the only problem I can think of is that the loading order would change, which may make it difficult for the programmer to predict the effects of interpositioning (if I'm remembering the correct term). -Brian On Wednesday, November 20, 2002, at 10:41 AM, Dmitry Orlov wrote: > Hi Brian, > > I think we should start using the integratis list - > int...@li... - for this sort of stuff, so I'm > cc'ing the list. > > This all sounds fine, except for where the find-class method lives. I > would move Root.find-class to Server.find-class since it's not > something > that happens to an object but to the server as a whole. > > For in-db, I think having two variants is OK, but the second should be > able to deal with multiple keys: > > ORMap.in-db ($class $path) > ORMap.in-db ($class @keys) > > I just thought briefly about Server.reload-class, which is slightly > tricky because it should *not* reload classes implemented as .so's. So, > I wonder, should it complain, or should it do what it can and fail > silently? I am not sure. If it's a mixed implementation class, one > could > reasonably want to reload just the reloadable methods. > > -Dmitry |
|
From: Dmitry O. <do...@ba...> - 2002-11-20 15:41:56
|
Hi Brian, I think we should start using the integratis list - int...@li... - for this sort of stuff, so I'm cc'ing the list. This all sounds fine, except for where the find-class method lives. I would move Root.find-class to Server.find-class since it's not something that happens to an object but to the server as a whole. For in-db, I think having two variants is OK, but the second should be able to deal with multiple keys: ORMap.in-db ($class $path) ORMap.in-db ($class @keys) I just thought briefly about Server.reload-class, which is slightly tricky because it should *not* reload classes implemented as .so's. So, I wonder, should it complain, or should it do what it can and fail silently? I am not sure. If it's a mixed implementation class, one could reasonably want to reload just the reloadable methods. -Dmitry Brian Reilly wrote: > > Dmitry, > > I encountered a situation that needed a little more support from > ORMap which needed a little more exposure of the C API than we > previously had. I wanted to run these by you first before checking > anything in. Here's the situation. > > I needed to be able to find out if an object exists, either in > hyperdata or in the database. However, I don't want to call > 'create' on the object because, if it doesn't exist in the > database, I don't want it to suddenly appear in hyperdata. It > seemed to make the most sense to use ORMap for this since it knows > how the object is stored in the database (metamodel, table, etc). > I added ORMap.in-db to do this. It takes two parameters: the name > of the class and an identifier for the object. The class name is > used to find the ORMap information from the class. The identifier > that should be passed to it depends on the ORMap mode being used... > the path for metamodel mode and the primary key for table and > custom modes. > > The only piece missing to implement that was the ability to find a > class based on its name. This isn't easy to do from a scripting > language because of the fact that the class hierarchy is > represented in the path to the class. However, we have an easy way > to get the path to a class from C using HD_findClass and > HD_getPath. I added Root.find-class that does this to return the > path to the class. Additionally, it attempts HD_loadClass if it > doesn't initially find it which is useful for a freshly started > server. > > What are your thoughts on these additions? I'm not sure that I > like ORMap.in-db but couldn't think of anything better... maybe > ORMap.exists-db? Do you have any suggestions? Also, Root may not > be the best place for find-class since it doesn't have any effect > on the object itself... it's just a utility function that I put > there to make it accessible from any object. However, it could > just as easily live in a new module... maybe HD.find-class or > something like that. > > -Brian |
|
From: Brian R. <br...@ba...> - 2002-05-09 14:46:21
|
More realistically, we should probably tag the repository before we make the tarball. Then, if we need to do commits to CVS, we'll know which revisions we need to re-apply once the Sourceforge CVS is up and running. We can certainly try to minimize the amount we have to commit while we wait but, especially since we don't know how long it will take, we shouldn't expect to eliminate the need entirely, IMHO. That said, I think end of the day today would probably be a good time to make the tarball. -Brian Dmitry Orlov wrote: > > I have asked Sourceforge to add our existing ,v files to the CVS > repository, and they have agreed. The procedure is for us to make a > tarball of the entire repository, let them know where they can grab it > from, and wait. Once we make the tarball, we should not do any more > commits on the old repository, but wait until the new repository becomes > available. I am not sure when the best time to do that would be, but I > was thinking later today or tomorrow would be good. > > -Dmitry > > _______________________________________________________________ > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > the hardware. You get the recognition. Email Us: ban...@so... > _______________________________________________ > Integratis-cvs mailing list > Int...@li... > https://lists.sourceforge.net/lists/listinfo/integratis-cvs |
|
From: Dmitry O. <do...@ba...> - 2002-05-09 14:37:51
|
I have asked Sourceforge to add our existing ,v files to the CVS repository, and they have agreed. The procedure is for us to make a tarball of the entire repository, let them know where they can grab it from, and wait. Once we make the tarball, we should not do any more commits on the old repository, but wait until the new repository becomes available. I am not sure when the best time to do that would be, but I was thinking later today or tomorrow would be good. -Dmitry |
|
From: Dmitry O. <do...@ba...> - 2002-05-08 20:06:56
|
test |
|
From: Dmitry O. <do...@ba...> - 2002-05-08 19:58:40
|
test |
|
From: Dmitry O. <do...@ba...> - 2002-05-08 19:57:01
|
test |
|
From: Dmitry O. <do...@ba...> - 2002-05-08 19:52:56
|
test |
|
From: Dmitry O. <do...@ba...> - 2002-05-08 19:41:50
|
This one better work for me as well as everyone else :( |
|
From: Dmitry O. <do...@ba...> - 2002-05-08 19:24:05
|
This is a test. |
