Questions just related to GemStone?

Is this a proper mailing list to ask general question about the usage of
GemStone?

If not, please let me know what would be the proper place.

I've a few maybe dumb questions.
1) one can use diverse Smalltalks (Pharo, Seaside, VWorks, Visual Aga
afaikt). It seems the Pharo smalltalk sit a favourite for Glass. What
about the status of other "Smalltalk" Frontends?

2) I have checked OODBS a few years ago and never really lost them
out-of-sight but have not ever written anything of substance in one of
them. Now my background is well a bit SQL and "RDBS".
However one thing is obvious, a lot of time is spend in the table Layout
for such kind of solutions. There are the divers normal forms etc. Now I
know that a bit, but how is it handled in GemStone. I know one could e.g
just drop some collections into members. So a 1:n relation ship may just
be an array/dictionary as the n part. So how does one do this Object
Layout. Are there good/bad examples freely accessible?

3) are the any examples on Gemstone usage accessible via some kind of
Repository etc?

4) If one does not use a Web-Frontend, what are the alternatives to make
"native" GUI Applications?

I hope I don't bother you too much with such kind of questions.

Regards
Friedrich




--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

On Sat, Sep 4, 2010 at 1:08 AM, Friedrich Dominicus
<[hidden email]> wrote:
> Is this a proper mailing list to ask general question about the usage of
> GemStone?
>
> If not, please let me know what would be the proper place.
>
> I've a few maybe dumb questions.
> 1) one can use diverse Smalltalks (Pharo, Seaside, VWorks, Visual Aga
> afaikt). It seems the Pharo smalltalk sit a favourite for Glass. What
> about the status of other "Smalltalk" Frontends?

Can you explain how you are using the word 'frontend' and what you mean by it?

Have you done any object oriented programming?
You are basically just constructing a normal object graph, ie modeling
your domain
and then saving it into a persistent root.

For example, I could have a ToDoListSystem that contains a collection
of ToDoList
Each ToDoList has many ToDoItem again stored as a collection. This
could be as simple as
ToDoList having an instance variable 'items' that gets initialized to
an OrderedCollection.
>
> 3) are the any examples on Gemstone usage accessible via some kind of
> Repository etc?

There is the gemsource monticello repository. http://seaside.gemstone.com/ss

> 4) If one does not use a Web-Frontend, what are the alternatives to make
> "native" GUI Applications?

Gemstone has no graphics classes. You can use gemstone as an object store
and use other Smalltalks to pull data in and out but unless you are
doing client/server
programming, there isnt any need for that. If you were just doing a
single user application
in smalltalk, the standard image would suit you fine. Think of
gemstone as what you
would use when you want to still work with an image but you want it to scale out
and deal with concurrency.

Sean Allen <[hidden email]> writes:
Ok if I start my GemStone I can connect to it via the Pharo
Smalltalk. So in this respect the Pharo smalltalk (the frontend)is used
to access Gemstone . I'm not starting the topaz CLI. In Pharo I do the
"development"....., but I can not use everything from Pharo because not
everything known to Pharo is known to the Gemstone Smallalk. So in fact
I'm using an the services the embedded Gemstone Smalltalk provides to
me. Is that correct?


> Have you done any object oriented programming?
Yes, quite much but not cared about "persistence"
> You are basically just constructing a normal object graph, ie modeling
> your domain
> and then saving it into a persistent root.
Ok let us take

class Person

    addresses...... (a person can have more than one address)

class Address

    zip
    city
    ....
....

So I have this two classes, but I want to have them separatly and an
address does not "naturally" belong to an Person. I "assign" an adress
to an person, but I keep the addresses separate. I may use e.g the same
address under different circumstances.

 
>
> For example, I could have a ToDoListSystem that contains a collection
> of ToDoList
> Each ToDoList has many ToDoItem again stored as a collection. This
> could be as simple as
> ToDoList having an instance variable 'items' that gets initialized to
> an OrderedCollection.
I'm quite aware of this. But in the example above I want to be able to
extend the classes separatly. I will have certain "dialogs" to modify
the Adresses etc.

>>
>> 3) are the any examples on Gemstone usage accessible via some kind of
>> Repository etc?
>
> There is the gemsource monticello
> repository. http://seaside.gemstone.com/ss
Thanks I have used it before but did not know it contains sort of
Applications also.
Agreed, but the question was about let's name it "fat-client"
applications. So maybe my englis is really much worse than I though it
is. I try it another way.

Let's take an access application. The frontend is "native" Windows but
it works in a Client/Server mode. That means the Backend (in our case
this would be Gemstone) sits somwhere and provide it's services. So in
the Frontend I can use whatever is offered by the smalltalk of
choice. Is that correct?

So I may use Pharos Morphic stuff, or VW gui classes or VisualAges gui
classes. But as you pointed out there are not "native" gui classes for
Gemstones Smalltalk do I have get that correctly?




> Think of
> gemstone as what you
> would use when you want to still work with an image but you want it to scale out
> and deal with concurrency.
I understand GemStone as indefinitely RAM ;-) which happens to "survive"
even during a shutdown.

Thanks for your attention.

Friedrich
--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

On Sat, Sep 4, 2010 at 2:44 AM, Friedrich Dominicus
<[hidden email]> wrote:
Not quite. There is a tool called GemTools which happens to be written in/run on
Pharo smalltalk that you can use to interact with Gemstone. Gemtools is a fairly
recent development. One of the biggest and most important points about
it: its free.
Pharo is not a front end however. Gemtools is.

You can do development in any Smalltalk you want, you just have to
port your code
to Gemstone. Joel Turnbull ( who I used to work with and still
frequents this list from time
to time ) is/was fond of doing his development just in Gemstone using
Gemtools. I find that way
of development to be rather lacking as you don't get the full breadth
of the Smalltalk tools.
The proscribed way to do development is to write your application in
Pharo and then port it
over to Gemstone. People ( in particular Dale ) have been working on
providing compatibility
been Pharo and Gemstone where possible in order to make this easier.
This usually means,
a Gemstone compat. library for Pharo as well as adding Pharo methods
that are missing from
Gemstone in.


And? I dont really get what you are getting at here.
Are you asking how you can have that object graph and use a person's address
in multiple locations?

I think your 'naturally' is really a red herring. Whether an address
belongs to a person
or not depends on the context. If I am writing a contact database that
deals with people
then an address belongs to a person. The address is meaningless
without the person.
If I am doing mapping software than people/business are indeed
assigned to particular address
and I would say, in that case, 'belong to' that address.

But again, that isn't really to the point. What is your question, how
can you store the address
so it is separate from the person? IE how can I get the address
without going through the person,
change it and have that change reflected in the person?


That has nothing to do with how it is persisted.
It has nothing to do with Gemstone. You can provide a dialog to modify
and address
and have the address only be available via an object graph traversal
that goes through
the person. I understand this to an extent. When you work everyday
with an RDBMS,
you tend to not see how that has changed your thinking.

Don't think about persistence. Persistence is basically unimportant
when using Gemstone.
Yes that is a weird statement but, it is true. Design your classes
without thinking about
how you are going to Persist them. Belong to and assign to as you are
using the terms
are about persistence, not application logic. A Person has many
addresses associated with them.

I think what you want to know is how do I map how I would do this with
an RDBMS to gemstone.
Well, that is a reasonable thought but remember, you shouldnt do a 1
to 1 mapping.

I go about it this way, I create a 'System' for each of the
classes/group of classes I need to manage.
For example: People. I have a PeopleSystem. You can add people to the
system, get a list of all the
people, query by specific parameters to find (
PeopleSystem>peopleNamed: aName ) etc. If I only
need addresses to be accessible through people, I stop there. If I
want to be able to edit an address
and that is done in the context of a person ( as in the address has no
meaning outside of being associated
with a person, see my contact book example above ) then this is all I
need. Lets say though, that I have a simple
e-commerce system, I have customers and orders and each has meaning
outside the other. I would have two
systems: CustomerSystem and OrderSystem. A Customer would still have a
collection of orders but now,
I don't have to go through the CustomerSystem and Customer to get at
orders. I can go through the OrderSystem
( OrderSystem>orderNumbered: anOrderNumber or OrderSystem>ordersFrom:
aStartDate to : anEndDate ) to get
orders I'm interested in. If I modify an order, it will be reflected
in the customer because its the same instance, just
accessed through different location. Different graph, same end node.

Make sense?

This is a pretty standard use of Gemstone outside of the GLASS world.
It is very common to write fat client in Visual Works and via ProxyObjects etc
use Gemstone has a data store. I'm not an expert in this area although
I understand
the ideas. Someone else would be better at explaining it. Note, that the tools
used to make this easier to do aren't free.

>
>> Think of
>> gemstone as what you
>> would use when you want to still work with an image but you want it to scale out
>> and deal with concurrency.
> I understand GemStone as indefinitely RAM ;-) which happens to "survive"
> even during a shutdown.
>

That is a definition that could really lead you astray.
James Foster did a great talk on how Gemstone works internally at
Smalltalks in BA last November.
There were some videos of that floating around but I dont know where they are.

James, if you are reading this, are those videos still around? I
thought they were on your vimeo but I can't find.

On 4 sep 2010, at 17:46, Sean Allen wrote:
> The proscribed way to do development is to write your application in
> Pharo and then port it
> over to Gemstone. People ( in particular Dale ) have been working on
> providing compatibility
> been Pharo and Gemstone where possible in order to make this easier.
> This usually means,
> a Gemstone compat. library for Pharo as well as adding Pharo methods
> that are missing from
> Gemstone in.

And run SmallLint/Slime in Pharo to detect compatibility issues before trying to port:
http://book.seaside.st/book/components/slime
http://www.lukas-renggli.ch/blog/slime
http://www.lukas-renggli.ch/blog/programmatically-run-lint

Stephan Eggermont

Sean Allen <[hidden email]> writes:

>
> But again, that isn't really to the point. What is your question, how
> can you store the address
> so it is separate from the person? IE how can I get the address
> without going through the person,
> change it and have that change reflected in the person?
Yes you are right and it's my fault I have just wrote it down, too
careless. And well after thinking about it yesterday I think I can use
some of the bags, sets, etc. to just store a "list" of addresses. (list
not in the sense of a data-structure) just something I can use to easily
access addresses modify them etc.


> the person. I understand this to an extent. When you work everyday
> with an RDBMS,
> you tend to not see how that has changed your thinking.
Thanks for that understanding. I had to admit this is what give me
troubles. E.g in an RDB I surely must see how to layout the Databases
and how to combine them to get a result.

E.g I'd probably have

AddressID 123
personID 123


select ... from Person, Addresses where
Person.AddressId = Addresses.Id and
...
other joins, conditions whatever


>
> Don't think about persistence. Persistence is basically unimportant
> when using Gemstone.
Well this is a bit difficult. As you may know this is a "crucial"
question in any DB project, and it's even more crucial for OR/Mappers.
And it's needs quite some work. This is what I wante to "avoid".

> Yes that is a weird statement but, it is true. Design your classes
> without thinking about
No I understand it let's say "with the brain" but it nothing let's name
it "second nature" to me.
>
> I think what you want to know is how do I map how I would do this with
> an RDBMS to gemstone.
> Well, that is a reasonable thought but remember, you shouldnt do a 1
> to 1 mapping.
Yes I think you are exactly right about this.
>
> I go about it this way, I create a 'System' for each of the
> classes/group of classes I need to manage.
> For example: People. I have a PeopleSystem. You can add people to the
> system, get a list of all the
> people, query by specific parameters to find (
> PeopleSystem>peopleNamed: aName ) etc. If I only
> need addresses to be accessible through people, I stop there.
I think I can follow, stupid question what do you use to keep the
"persons" together. A RCIdentityBag (I think this is the name of it in
Gemstone).


Yes, that answers my "intended" question.
>
> This is a pretty standard use of Gemstone outside of the GLASS world.
> It is very common to write fat client in Visual Works and via ProxyObjects etc
> use Gemstone has a data store. I'm not an expert in this area although
> I understand
> the ideas. Someone else would be better at explaining it. Note, that the tools
> used to make this easier to do aren't free.
This is not a hindrance but sounds good. So I can find "support", that's
great.
Thank you very mucht for that confirmation. So I'm not totally lost ;-)

I just want to thank you again for alll the time you spend to decipher
my "writing". So I get more and more convince that my idea may not be
that unsound....

Best wishes
Friedrich



--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

On Sun, Sep 5, 2010 at 3:14 AM, Friedrich Dominicus
<[hidden email]> wrote:
Whichever RC class would be appropriate. In this particular example case,
you have selected what I would consider the proper collection class to
use to store them.

Friedrich Dominicus wrote:
Try this approach. Start from an ER diagram. Where you have primary keys
and foreign keys that realize the relationships between the entities,
think instead of using an object stored in an instance variable. For a
one-to-one relationship, store the related object directly in the
instance variable. For a one-to-many relationship, store a collection of
the related objects.

Now think about navigation. For each relationship, you need to decide
which direction you need to navigate: from class A to class B, the other
way around, or both ways. Some boilerplate code will help greatly, here.
The tricky part is the update. When the navigation is in both
directions, you need to update the links in both objects. If you don't
get this right, you'll get the equivalent of a foreign key constraint
violation. You don't encounter this problem in an RDB because you only
ever save the foreign key id on one side of the relationship, and use a
join to find the matching rows, when you're navigating from the side
that does not hold the foreign key.

Now consider the entities represented by the ER diagram. Think of the
entities as an object graph. You need to decide which entities are the
starting points, from which you can start navigating the graph. You will
need to provide some kind of search on all instances of the
entity/classes that are the starting points. You don't need to consider
this in an RDB because all classes/tables can be queried.

Ad hoc navigation is provided by an RDB, but it comes at the cost that
it is done for all entities. You cannot avoid the cost of indexing and
joining.

The other thing to consider is what kind of collection to use for
one-to-many relationships. Each relationship may benefit from using:
OrderededCollection, Set, or Dictionary, depending on how it needs to be
accessed.

Hope that helps.

--
Yanni Chiu