gemstone users?
Locked
 
|
Hi,
I'm trying to decide on a platform for a new project and I'm considering VW with Gemstone. I'm looking for something where persistant model classes can be added at runtime. The database itself will be structured as a network with the dynamically added classes as nodes and the relationships between them defined by links. I'm assuming there's no restriction to adding classes dynamically within deployed VW apps. I know i can do this with a relational backend, but my sense is that queries involving multiple classes will quickly degrade because if a class can be linked to any other class, and each is persisted in a separate table, the number of joins or subqueries for each item could equal the number of types in the system. Does anybody have similar experiences who could comment on the general architecture approach and/or on using Gemstone in particular? Thanks. |
|
|
There are no restrictions on using the compiler in any way in a deployed
application. We stopped doing that before VW went to Cincom. At 12:12 PM 2/19/2006, you wrote: >Hi, > >I'm trying to decide on a platform for a new project and I'm considering >VW with Gemstone. I'm looking for something where persistant model >classes can be added at runtime. The database itself will be structured >as a network with the dynamically added classes as nodes and the >relationships between them defined by links. > >I'm assuming there's no restriction to adding classes dynamically within >deployed VW apps. > >I know i can do this with a relational backend, but my sense is that >queries involving multiple classes will quickly degrade because if a class >can be linked to any other class, and each is persisted in a separate >table, the number of joins or subqueries for each item could equal the >number of types in the system. > >Does anybody have similar experiences who could comment on the general >architecture approach and/or on using Gemstone in particular? > >Thanks. <Talk Small and Carry a Big Class Library> James Robertson, Product Manager, Cincom Smalltalk http://www.cincomsmalltalk.com/blog/blogView |
|
|
In reply to this post by larrry
Larry,
On 20/02/06, Larry White <[hidden email]> wrote: > I'm assuming there's no restriction to adding classes dynamically within > deployed VW apps. Both VW and GemStone will let you progtamatically add new classes. > Does anybody have similar experiences who could comment on the general > architecture approach and/or on using Gemstone in particular? I have never deployed an app that created classes on the fly, so I don't have the experience to comment on what issues you might run into. The idea of creating new classes to represent network nodes does strike me as being odd (unless the classes represent *kinds* of nodes, perhaps). In relational terms, this would be like creating a table for each network node, but having no rows in the tables - I don't understand how that would work. I can't imagine any application model in VW that could not also be represented in GemStone. Both are "just" Smalltalk in this regard. All the best, Bruce -- Make the most of your skills - with OpenSkills http://www.openskills.org/ |
|
|
In reply to this post by larrry
Larry,
I've not used
Gemstone for about 12 years, but I can confirm that the general architectural
approach works fine with VW and an OODBMS. One thing to be wary of with VW is
the major slowdown in creating new classes since BindingReference etc. were
added (5i-7). If your classes have no new behavior of their own, and do not
affect existing name bindings, you should be able to shortcut VW's desire to
#relinkSystem after every new class. If you need to relink, you can batch
multiple class creations into one relink.
Another thing to be
aware of is the "format" instance variable of classes, which encodes the
total number of instance variables that instances of that class have. Saving new
persistent classes normally is fine, and the value of format is stored with
each. However, if you add a new instance variable to the non-persistent
superclass of the persistent classes, at a time when the persistent classes are
not loaded, next time you load them their format will still reflect the old
number of instance variables, and you'll have to update it
yourself.
Most OODBMSs also
have problems with class instance variables in persistent classes. Some cannot
even store values for these, others will not let you add new ones in persistent
subclasses. Also, OODBMS support for namespaces varies, and is unlikely to match
VW perfectly - if you can stuff all your persistent classes into one namespace,
preferably Smalltalk, so much the better!
Finally, you'll need
to be aware of the behavior of #flushVMmethodCache[EntriesFor:]. It's rather
disconcerting when you can see that the source code of your method matches the
CompiledCode bytecode, but the behavior when you actually run it is different!
It doesn't help that the method comments in the #flushVMmethodCache stuff are
more descriptive of what might once have been envisaged to be done, rather than
what actually happens ;-). If you can accept the performance loss of flushing
the entire native code cache after every class creation or structure change, you
don't need to worry about this at all (highly recommended for ongoing mental
health!).
Having said all
this, please be aware that my comments are based on the problems encountered
over 13 years, all have been few and far between over that time, and I was using
different VW versions and a different OODBMS.
All the
best,
Steve
-- Steven Kelly, CTO, MetaCase, http://www.metacase.com/blogs/stevek/blogView > > > > "The most significant innovation over the next 10 years" < < < < Bill Gates on Domain-Specific Modeling, www.adtmag.com/article.asp?id=9166
|
|
|
In reply to this post by larrry
Just a quick
addition:
If your
persistent classes have no behavior of their own, you might want to consider not
using classes at all. As a general concept, classes have two things:
behavior, and instances with instance variables. VW makes Behavior the
root of the Class class hierarchy, which
means you can have Class-like things with just behavior and no ability to make
instances with new instance variables, but not Class-like things with the
ability to make instances with new instance variables, but with no new behavior.
If all you need is instances with new instance variables, you might well be
better off making your own mechanism for adding instance variables. At the end
of the day all ivs are is an array, and adding an iv simply goes through all
instances and inserts a new slot at the appropriate point in the array. You can
either duplicate that with a real Array, OrderedCollection, or even a Dictionary
(which removes the need to go through all instances when adding an iv, since you
can use #at:ifAbsentPut:[defaultValue]).
So your MySuperclassOfAllPersistentClasses would have
an iv "fakeInstVarDict" or something like that, containing associations of
instVarName->instVarValue, along with another called "type", which would
point to an instance of MyInstVarInfoForPersistentSubclasses.
An approach like this - if possible in your case -
would save you from fighting VW's mechanisms for updating the system on class
changes (#relinkSystem, #flushVMmethodCache). It would also make your code a lot
more portable to other languages and DBs, and more flexible in what semantics
you want to attach to a class having an iv. Of course, that flexibility also
means more work and more potential potholes: you're essentially creating a
significant part of the semantics of an OO programming language yourself.
Cheers,
Steve
|
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |