Experiences with non RDBs?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Experiences with non RDBs?

FDominicus
I just  wonder about experiences with non relational databases like e.g
- Magma
- Gemstone
- others

and/or limits of the diverse ORM mappers.
- Glorp
- Magritte
- others

Regards
Friedrich


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

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Experiences with non RDBs?

Igor Stasenko
On 7 April 2010 09:41, Friedrich Dominicus
<[hidden email]> wrote:

> I just  wonder about experiences with non relational databases like e.g
> - Magma
> - Gemstone
> - others
>
> and/or limits of the diverse ORM mappers.
> - Glorp
> - Magritte
> - others
>
Try out my creation -  SCouchDB  (squeaksource.com/SCouchDB) :)

There is a object<->couch document mapping, but little limited:
you can store any object as document, but object's variable values
(indexed/ivars) should be of primitive type, recognized by json -
strings/numbers/arrays etc.

I am still new to CouchDB myself, but i'm very excited about hot its
easy to use its API,
and how easy to implement a glue code for it.

adaptor := SCouchDBAdaptor new host: 'localhost' port: 5984.
database := adaptor ensureDatabase: 'myDB'.

"store"
database at: 1 put: 10.
database at: 2 put: #(1 2 3 4 5 6 7 8 9 10).
database at: 3 put: 100@100.

"retrieve"

x := database at: 1.
y := database at: 2.
point := database at: 3.

> Regards
> Friedrich
>
>
> --
> Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
> Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Experiences with non RDBs?

Stéphane Ducasse
In reply to this post by FDominicus
I know

        Inceptive.be is using GOODS.
        Hilaire used magma
        Netstyle.ch postgres

Now this is easter holidays here so people are busy eating chocolate.

Stef

On Apr 7, 2010, at 8:41 AM, Friedrich Dominicus wrote:

> I just  wonder about experiences with non relational databases like e.g
> - Magma
> - Gemstone
> - others
>
> and/or limits of the diverse ORM mappers.
> - Glorp
> - Magritte
> - others
>
> Regards
> Friedrich
>
>
> --
> Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
> Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Experiences with non RDBs?

NorbertHartl
And I'm using gemstone :)

All of the persistence solutions have specialities that make them useful. Be it

- GOODS that is supposed to be language neutral. You can share your objects between smalltalk and java e.g.
- Magma is smalltalk only but full-featured OODB that is easy to set up and it is quite powerful. For server deployment I can't say. It is that Chris always states that you can achieve decent performance but other people always complain about its performance
- CouchDB/document databases. Is also kind of language neutral. When "just persist and query" is your main concern (which is it most of the time) than CouchDB might be a good choice. With this you can access your objects from either the server or from the client using javascript. Should be fairly ease to do
- gemstone if you consider persistence as just a necessity because your memory is not persisted by default and it is too small to keep everything. Or in other words if you just want to care about _your_ problems and not the problem of the persistence ;)
- SQL to integrate legacy application or to feature a business problem that is relational in its nature which OO problems are not per se
- XMLDB if your problem domain is not only about document but about XML documents and X**** search capabilties.

And there a lot more that are combinations of any of the above etc.

Norbert

On 07.04.2010, at 12:36, Stéphane Ducasse wrote:

> I know
>
> Inceptive.be is using GOODS.
> Hilaire used magma
> Netstyle.ch postgres
>
> Now this is easter holidays here so people are busy eating chocolate.
>
> Stef
>
> On Apr 7, 2010, at 8:41 AM, Friedrich Dominicus wrote:
>
>> I just  wonder about experiences with non relational databases like e.g
>> - Magma
>> - Gemstone
>> - others
>>
>> and/or limits of the diverse ORM mappers.
>> - Glorp
>> - Magritte
>> - others
>>
>> Regards
>> Friedrich
>>
>>
>> --
>> Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
>> Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Experiences with non RDBs?

Mariano Martinez Peck
In reply to this post by FDominicus
Hi Friederich:  few weeks ago we have a interesting discussion. As a good programmer, we should reuse :)

http://n4.nabble.com/databases-td1558285.html#a1559265

http://n4.nabble.com/databases-td1558558.html#a1559709


On Wed, Apr 7, 2010 at 8:41 AM, Friedrich Dominicus <[hidden email]> wrote:
I just  wonder about experiences with non relational databases like e.g

The only project I used was Glorp...but I will answer you the little I know.
 
- Magma

Is a OODB that seems to work pretty good. Now it is very easy to install in Pharo using the Metacello ConfigurationOfMagma.
Notice that Magma work only in Pharo / Squeak as I am aware of.
Some people say the performance is good and other not very good.
 
- Gemstone

GLASS seems to be an excellent choice for several projects. You can just download the VMWare and run it. I think it fits well for midium/big projects.
It is good that you can scale A LOT. OF course, if you scale a lot, you will probably have to pay. Look at the GLASS conditions.
Another important thing is that Gemstone is the Smalltalk in itself. It is not like magma. IT IS AN SMALLTALK, but that supports ACID ;)
So...you may have some little problems while migrating from Pharo to Gemstone as some messages may behave diffrently. Or maybe even don't have some classes in one smalltalk but yes in the other one.

Gemstone is headless. So, you cannot develop in Gemstone. You need a GemClient. So...and excellent choice is to develop with Pharo and deploy to Gemstone...
 
- others

and/or limits of the diverse ORM mappers.
- Glorp

Glorp is developed in VW. The port to squeak/pharo is old. I only supports posgresql backend. To fix that, we developed GlorpDBX.
For more information, read: http://www.squeakdbx.org/GLORP integration
We have it working with PostgreSQL, MySQL and Oracle.
 
Cheers

Mariano

- Magritte
- others

Regards
Friedrich


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

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Experiences with non RDBs?

FDominicus
In reply to this post by FDominicus
Friedrich Dominicus <[hidden email]> writes:

> I just  wonder about experiences with non relational databases like e.g
> - Magma
> - Gemstone
> - others
Ok to  get a bit more concrete assume I have a simple inheritance as
in the  example

Object subclass: #ClosedFigure
        instanceVariableNames: 'sideA sideB sideC alpha beta gamma'
        classVariableNames: ''
        poolDictionaries: ''
        category: 'Pharo-Mailing-List-Example'!

!ClosedFigure methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:21'!
area
        ^0 ! !

!ClosedFigure methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 07:07'!
circumreference
        ^ 0! !



Object subclass: #ModelLine
        instanceVariableNames: 'length beginPoint endPoint'
        classVariableNames: ''
        poolDictionaries: ''
        category: 'Pharo-Mailing-List-Example'!

!ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'!
beginPoint
        ^ beginPoint! !

!ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'!
beginPoint: anObject
        beginPoint := anObject! !

!ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'!
endPoint
        ^ endPoint! !

!ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'!
endPoint: anObject
        endPoint := anObject! !

!ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'!
length
        ^ length! !

!ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'!
length: anObject
        length := anObject! !


!ModelLine methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 07:19'!
initialize
        super initialize.
        length := 0.! !

"-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!

ModelLine class
        instanceVariableNames: ''!

!ModelLine class methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 07:33'!
new: initialLength
        ^ self new length: initialLength
        ! !


ClosedFigure subclass: #ModelRectangle
        instanceVariableNames: 'lengthSideA lengthSideB'
        classVariableNames: ''
        poolDictionaries: ''
        category: 'Pharo-Mailing-List-Example'!

!ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'!
lengthSideA
        ^ lengthSideA! !

!ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'!
lengthSideA: anObject
        lengthSideA := anObject! !

!ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'!
lengthSideB
        ^ lengthSideB! !

!ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'!
lengthSideB: anObject
        lengthSideB := anObject! !


!ModelRectangle methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:35'!
area
        ^ lengthSideA * lengthSideB ! !

!ModelRectangle methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:32'!
lengthSideA: lenA lengthSideB: lenB
        super initialize.
        lengthSideA := lenA.
        lengthSideB  := lenB.! !

"-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!

ModelRectangle class
        instanceVariableNames: ''!

!ModelRectangle class methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:39'!
lengthSideA: lenA lengthSideB: lenB
        ^ self new lengthSideA: lenA lengthSideB: lenB.! !


ClosedFigure subclass: #ModelTriangle
        instanceVariableNames: 'height length'
        classVariableNames: ''
        poolDictionaries: ''
        category: 'Pharo-Mailing-List-Example'!

!ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:51'!
area
        ^ 1/2 * length  * height ! !

!ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'!
height
        ^ height! !

!ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'!
height: anObject
        height := anObject! !

!ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'!
length
        ^ length! !

!ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'!
length: anObject
        length := anObject! !


!ModelTriangle methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:47'!
length: aLength  height: aHeight
        super initialize.
        length := aLength.
        height:= aHeight. ! !

"-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!

ModelTriangle class
        instanceVariableNames: ''!

!ModelTriangle class methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:49'!
length: aLength  height: aHeight
        ^ self new length: aLength  height: aHeight.! !



Now this is as simple as can be. I have a Parent and two derived
classes. How would I make this stuff persistent, and how would it look
in different persistence solutions.

Let us assume. I would store the outline e.g in an OrderedCollection of
Lines or whatever. What about other "ClosedFigures" like e.g circles,
ellipses etc. How do  I model inheritance in the diverse OR mappers. How
does that work in let's say
- Magma
- Glorp
- GemStone
- whatever you choose

How would  I query the database on let's side length of some lines of
the Closed Figure, or let's say I like to query a few closed figures on
their circumreference or area.

Or asked anotherway. How is inheritance handled in the diverse
persistence tools..

Another question is how easy or difficult is it to have let's say
something like a person with addresses, phone numbers etc.

How would I have to query let's say the street address of a certain
Person. e.g

Regards
Friedrich

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

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Experiences with non RDBs?

Igor Stasenko
On 8 April 2010 10:02, Friedrich Dominicus
<[hidden email]> wrote:
> Friedrich Dominicus <[hidden email]> writes:
>
>> I just  wonder about experiences with non relational databases like e.g
>> - Magma
>> - Gemstone
>> - others
> Ok to  get a bit more concrete assume I have a simple inheritance as
> in the  example
>
[snip]

> Or asked anotherway. How is inheritance handled in the diverse
> persistence tools..
>
> Another question is how easy or difficult is it to have let's say
> something like a person with addresses, phone numbers etc.
>
> How would I have to query let's say the street address of a certain
> Person. e.g
>
I can't say for OR mappers, but for OODBs like Gemstone or Magma,
everything is handled seamlessly.
You need to care only about your data model, and can do anything, what
naturally you
want to do with your data. OODB handling all of it behind the scenes.
All what is you have to do is to designate the transaction boundaries,
where you dealing with data,
so you can abort /commit it at some logical point.
The rest of stuff can be used without caring about persistence - you
working with objects as if they
are just objects , as if you having your data in image. As simple as that.

Of course, there are indexes and other helpful stuff, which could help
you work more efficiently with larger data sets,
but it is optional.
So, while in RDBMS your are a servant of database (because you have to
follow all requirements
for every query/data model you put there), with OODB - it is a
database your servant and doing everything
for you, without much interference and without dictating you how your
data structures should be organized.
So, i think this answering your question about inheritance: if you
need inheritance, just use it. :)

> Regards
> Friedrich
>
> --
> Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
> Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Experiences with non RDBs?

NorbertHartl
In reply to this post by FDominicus
Hi,

I think I don't need to refer to your concrete example. Basically an object is a named key-value store. So a class A with instance variable a,b,c is just something like

A
  a -> valueOfA
  b -> valueOfB
  c -> valueOfC

A subclass of A would either have the same amount of variables or more. So subclass B of A could look like

B
  a -> valueOfA
  b -> valueOfB
  c -> valueOfC
  d -> valueOfD

If you have a serialized form of a B you need to know that it is a B in order to read all of the 4 values back into the right object type.

- in OODBs this case is easy. The serialization contains everything from the key-values and the class that they belong to. Sometimes the data format on disk is the same as in memory so there is less to do. The difference between magma and gemstone is that magma is an addition to an image. That means you have your smalltalk image in memory and than you have magma. With magma you define a persisted root object, e.g. a Dictionary. Everything you attach to the Dictionary will be persisted if you do a commit. Well, you need to do your changes inside a transaction but there are always ways to make this look nearly transparent. In gemstone everything is already persisted including all the classes and objects. As soon as you attach a newly created object somewhere that is already persistent it will be persisted, too. The easiest way of handling your data is to keep an instance variable in your class that holds the instances. Et voila, that's all! All you objects are persisted. Speaking of seaside gemstone can be used doing autocommits on a request basis so you don't have to care at all about transactions. You just use your objects and that is it. Querying is like using collections. If you need special kind of querying either for your problem or performance you can provide a special type of collection that is optimized for the problem

- In XMLDBs / document databases (CouchDB) you just have a representation of that key-value store. Be it an xml element or a Javascript object in JSON format they are both key-value stores. You then need to serialize/deserialize those formats. Reading a subclass is just a matter of providing the right class name when reading the serialized format. References can be handled multiple ways, but default ones will be id/idref in XML and link/Uri in restful ways. Querying in XMLDB is using xpath, in CouchDB and document databases I don't know if there is a general query support

- In SQL databases the instance variables are mapped to columns of a table or multiple tables and each row is an object. Relationships of objects are handled by keys in the tables. A 1:1 relationships contains a key of the relation source in the relation target table. A n:m relationship needs an intermediate table that maps relation source keys to relation target keys. Talking about inheritance this gets easily complicated. Basically there are two options. You can solve it like everyone would expect it, let's say more BNF like. You would have a table A for class A and a table B for class B. Now in all tables of objects that reference A or B you need an additional information which class is meant: A or B. The tables than could be joint correctly after evaluation the additional value. Another strategy is to do multiple lookups until you've found the right value. The other approach is to make one table that is a super set of all needed variables. The keys are unique among all the subclasses and can be lookuped up more easily. But you waste some space because a lot of the columns would be empty. In any case you need to change your database schema if you change your model. Joins and number of requests can grow easily so that your application will be slowed down. Glorp gives you all of these strategies if you want them. My personal advize would be to avoid inheritance in that scenario completely or do only the simplest cases possible. Relational databases and object oriented approaches just don't fit together. You need to decide if your problem is more of the one or the other type. Then take one of those two approaches. Querying is based on column types and joins. Glorp is providing a query protocol that is similar to collections. You just need to use some things differently due to the nature of the layer below is different.

Hope this helps,

Norbert



On 08.04.2010, at 09:02, Friedrich Dominicus wrote:

> Friedrich Dominicus <[hidden email]> writes:
>
>> I just  wonder about experiences with non relational databases like e.g
>> - Magma
>> - Gemstone
>> - others
> Ok to  get a bit more concrete assume I have a simple inheritance as
> in the  example
>
> Object subclass: #ClosedFigure
> instanceVariableNames: 'sideA sideB sideC alpha beta gamma'
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Pharo-Mailing-List-Example'!
>
> !ClosedFigure methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:21'!
> area
> ^0 ! !
>
> !ClosedFigure methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 07:07'!
> circumreference
> ^ 0! !
>
>
>
> Object subclass: #ModelLine
> instanceVariableNames: 'length beginPoint endPoint'
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Pharo-Mailing-List-Example'!
>
> !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'!
> beginPoint
> ^ beginPoint! !
>
> !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'!
> beginPoint: anObject
> beginPoint := anObject! !
>
> !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'!
> endPoint
> ^ endPoint! !
>
> !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'!
> endPoint: anObject
> endPoint := anObject! !
>
> !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'!
> length
> ^ length! !
>
> !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'!
> length: anObject
> length := anObject! !
>
>
> !ModelLine methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 07:19'!
> initialize
> super initialize.
> length := 0.! !
>
> "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!
>
> ModelLine class
> instanceVariableNames: ''!
>
> !ModelLine class methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 07:33'!
> new: initialLength
> ^ self new length: initialLength
> ! !
>
>
> ClosedFigure subclass: #ModelRectangle
> instanceVariableNames: 'lengthSideA lengthSideB'
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Pharo-Mailing-List-Example'!
>
> !ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'!
> lengthSideA
> ^ lengthSideA! !
>
> !ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'!
> lengthSideA: anObject
> lengthSideA := anObject! !
>
> !ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'!
> lengthSideB
> ^ lengthSideB! !
>
> !ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'!
> lengthSideB: anObject
> lengthSideB := anObject! !
>
>
> !ModelRectangle methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:35'!
> area
> ^ lengthSideA * lengthSideB ! !
>
> !ModelRectangle methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:32'!
> lengthSideA: lenA lengthSideB: lenB
> super initialize.
> lengthSideA := lenA.
> lengthSideB  := lenB.! !
>
> "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!
>
> ModelRectangle class
> instanceVariableNames: ''!
>
> !ModelRectangle class methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:39'!
> lengthSideA: lenA lengthSideB: lenB
> ^ self new lengthSideA: lenA lengthSideB: lenB.! !
>
>
> ClosedFigure subclass: #ModelTriangle
> instanceVariableNames: 'height length'
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Pharo-Mailing-List-Example'!
>
> !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:51'!
> area
> ^ 1/2 * length  * height ! !
>
> !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'!
> height
> ^ height! !
>
> !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'!
> height: anObject
> height := anObject! !
>
> !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'!
> length
> ^ length! !
>
> !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'!
> length: anObject
> length := anObject! !
>
>
> !ModelTriangle methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:47'!
> length: aLength  height: aHeight
> super initialize.
> length := aLength.
> height:= aHeight. ! !
>
> "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!
>
> ModelTriangle class
> instanceVariableNames: ''!
>
> !ModelTriangle class methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:49'!
> length: aLength  height: aHeight
> ^ self new length: aLength  height: aHeight.! !
>
>
>
> Now this is as simple as can be. I have a Parent and two derived
> classes. How would I make this stuff persistent, and how would it look
> in different persistence solutions.
>
> Let us assume. I would store the outline e.g in an OrderedCollection of
> Lines or whatever. What about other "ClosedFigures" like e.g circles,
> ellipses etc. How do  I model inheritance in the diverse OR mappers. How
> does that work in let's say
> - Magma
> - Glorp
> - GemStone
> - whatever you choose
>
> How would  I query the database on let's side length of some lines of
> the Closed Figure, or let's say I like to query a few closed figures on
> their circumreference or area.
>
> Or asked anotherway. How is inheritance handled in the diverse
> persistence tools..
>
> Another question is how easy or difficult is it to have let's say
> something like a person with addresses, phone numbers etc.
>
> How would I have to query let's say the street address of a certain
> Person. e.g
>
> Regards
> Friedrich
>
> --
> Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
> Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Experiences with non RDBs?

Stéphane Ducasse
In reply to this post by FDominicus
in SqueakSafe (developed at HPI) they use traits exactly to be able to plug persistency in an existing domain
single inheritance.

Stef


On Apr 8, 2010, at 9:02 AM, Friedrich Dominicus wrote:

> Friedrich Dominicus <[hidden email]> writes:
>
>> I just  wonder about experiences with non relational databases like e.g
>> - Magma
>> - Gemstone
>> - others
> Ok to  get a bit more concrete assume I have a simple inheritance as
> in the  example
>
> Object subclass: #ClosedFigure
> instanceVariableNames: 'sideA sideB sideC alpha beta gamma'
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Pharo-Mailing-List-Example'!
>
> !ClosedFigure methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:21'!
> area
> ^0 ! !
>
> !ClosedFigure methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 07:07'!
> circumreference
> ^ 0! !
>
>
>
> Object subclass: #ModelLine
> instanceVariableNames: 'length beginPoint endPoint'
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Pharo-Mailing-List-Example'!
>
> !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'!
> beginPoint
> ^ beginPoint! !
>
> !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'!
> beginPoint: anObject
> beginPoint := anObject! !
>
> !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'!
> endPoint
> ^ endPoint! !
>
> !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'!
> endPoint: anObject
> endPoint := anObject! !
>
> !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'!
> length
> ^ length! !
>
> !ModelLine methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 07:09'!
> length: anObject
> length := anObject! !
>
>
> !ModelLine methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 07:19'!
> initialize
> super initialize.
> length := 0.! !
>
> "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!
>
> ModelLine class
> instanceVariableNames: ''!
>
> !ModelLine class methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 07:33'!
> new: initialLength
> ^ self new length: initialLength
> ! !
>
>
> ClosedFigure subclass: #ModelRectangle
> instanceVariableNames: 'lengthSideA lengthSideB'
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Pharo-Mailing-List-Example'!
>
> !ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'!
> lengthSideA
> ^ lengthSideA! !
>
> !ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'!
> lengthSideA: anObject
> lengthSideA := anObject! !
>
> !ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'!
> lengthSideB
> ^ lengthSideB! !
>
> !ModelRectangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:31'!
> lengthSideB: anObject
> lengthSideB := anObject! !
>
>
> !ModelRectangle methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:35'!
> area
> ^ lengthSideA * lengthSideB ! !
>
> !ModelRectangle methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:32'!
> lengthSideA: lenA lengthSideB: lenB
> super initialize.
> lengthSideA := lenA.
> lengthSideB  := lenB.! !
>
> "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!
>
> ModelRectangle class
> instanceVariableNames: ''!
>
> !ModelRectangle class methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:39'!
> lengthSideA: lenA lengthSideB: lenB
> ^ self new lengthSideA: lenA lengthSideB: lenB.! !
>
>
> ClosedFigure subclass: #ModelTriangle
> instanceVariableNames: 'height length'
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Pharo-Mailing-List-Example'!
>
> !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:51'!
> area
> ^ 1/2 * length  * height ! !
>
> !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'!
> height
> ^ height! !
>
> !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'!
> height: anObject
> height := anObject! !
>
> !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'!
> length
> ^ length! !
>
> !ModelTriangle methodsFor: 'accessing' stamp: 'FriedrichDominicus 4/8/2010 08:46'!
> length: anObject
> length := anObject! !
>
>
> !ModelTriangle methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:47'!
> length: aLength  height: aHeight
> super initialize.
> length := aLength.
> height:= aHeight. ! !
>
> "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!
>
> ModelTriangle class
> instanceVariableNames: ''!
>
> !ModelTriangle class methodsFor: 'as yet unclassified' stamp: 'FriedrichDominicus 4/8/2010 08:49'!
> length: aLength  height: aHeight
> ^ self new length: aLength  height: aHeight.! !
>
>
>
> Now this is as simple as can be. I have a Parent and two derived
> classes. How would I make this stuff persistent, and how would it look
> in different persistence solutions.
>
> Let us assume. I would store the outline e.g in an OrderedCollection of
> Lines or whatever. What about other "ClosedFigures" like e.g circles,
> ellipses etc. How do  I model inheritance in the diverse OR mappers. How
> does that work in let's say
> - Magma
> - Glorp
> - GemStone
> - whatever you choose
>
> How would  I query the database on let's side length of some lines of
> the Closed Figure, or let's say I like to query a few closed figures on
> their circumreference or area.
>
> Or asked anotherway. How is inheritance handled in the diverse
> persistence tools..
>
> Another question is how easy or difficult is it to have let's say
> something like a person with addresses, phone numbers etc.
>
> How would I have to query let's say the street address of a certain
> Person. e.g
>
> Regards
> Friedrich
>
> --
> Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
> Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Experiences with non RDBs?

FDominicus
In reply to this post by NorbertHartl
Norbert Hartl <[hidden email]> writes:

> - in OODBs this case is easy. The serialization contains everything
> from the key-values and the class that they belong to. Sometimes the
> data format on disk is the same as in memory so there is less to
> do. The difference between magma and gemstone is that magma is an
> addition to an image. That means you have your smalltalk image in
> memory and than you have magma. With magma you define a persisted root
> object, e.g. a Dictionary. Everything you attach to the Dictionary
> will be persisted if you do a commit. Well, you need to do your
> changes inside a transaction but there are always ways to make this
> look nearly transparent. In gemstone everything is already persisted
> including all the classes and objects. As soon as you attach a newly
> created object somewhere that is already persistent it will be
> persisted, too. The easiest way of handling your data is to keep an
> instance variable in your class that holds the instances. Et voila,
> that's all! All you objects are persisted. Speaking of seaside
> gemstone can be used doing autocommits on a request basis so you don't
> have to care at all about transactions. You just use your objects and
> that is it. Querying is like using collections. If you need special
> kind of querying either for your problem or performance you can
> provide a special type of collection that is optimized for the problem
Are there any examples around showing that?

>
> - In SQL databases the instance variables are mapped to columns of a
> table or multiple tables and each row is an object. Relationships of
> objects are handled by keys in the tables. A 1:1 relationships
> contains a key of the relation source in the relation target table. A
> n:m relationship needs an intermediate table that maps relation source
> keys to relation target keys. Talking about inheritance this gets
> easily complicated. Basically there are two options. You can solve it
> like everyone would expect it, let's say more BNF like. You would have
> a table A for class A and a table B for class B. Now in all tables of
> objects that reference A or B you need an additional information which
> class is meant: A or B. The tables than could be joint correctly after
> evaluation the additional value. Another strategy is to do multiple
> lookups until you've found the right value. The other approach is to
> make one table that is a super set of all needed variables. The keys
> are unique among all the subclasses and can be lookuped up more
> easily. But you waste some space because a lot of the columns would be
> empty. In any case you need to change your database schema if you
> change your model. Joins and number of requests can grow easily so
> that your application will be slowed down. Glorp gives you all of
> these strategies if you want them. My personal advize would be to
> avoid inheritance in that scenario completely or do only the simplest
> cases possible. Relational databases and object oriented approaches
> just don't fit together.
Well that was what liked to get shown. I was thinking in the simples
possible cases of inheritance and how "bad/good" that works with RDBs.

So I wanted to know if someone has done some work on ORM to handle that
with not too much pain on "my side".

I expected something like that. Either you build you stuff that it fits
the RDB model  or you better avoid RDBs. I have tried  to  figure
that out e.g in Rails but it all comes short if  "even" simple
inheritance comes into play. You message just confirms this impression.

Any way my question still  persists,  are there anywhere examples on
handling inheritance in ORMs?

Regards
Friedrich


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

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Experiences with non RDBs?

NorbertHartl

On 08.04.2010, at 12:35, Friedrich Dominicus wrote:

> Norbert Hartl <[hidden email]> writes:
>
>> - in OODBs this case is easy. The serialization contains everything
>> from the key-values and the class that they belong to. Sometimes the
>> data format on disk is the same as in memory so there is less to
>> do. The difference between magma and gemstone is that magma is an
>> addition to an image. That means you have your smalltalk image in
>> memory and than you have magma. With magma you define a persisted root
>> object, e.g. a Dictionary. Everything you attach to the Dictionary
>> will be persisted if you do a commit. Well, you need to do your
>> changes inside a transaction but there are always ways to make this
>> look nearly transparent. In gemstone everything is already persisted
>> including all the classes and objects. As soon as you attach a newly
>> created object somewhere that is already persistent it will be
>> persisted, too. The easiest way of handling your data is to keep an
>> instance variable in your class that holds the instances. Et voila,
>> that's all! All you objects are persisted. Speaking of seaside
>> gemstone can be used doing autocommits on a request basis so you don't
>> have to care at all about transactions. You just use your objects and
>> that is it. Querying is like using collections. If you need special
>> kind of querying either for your problem or performance you can
>> provide a special type of collection that is optimized for the problem
> Are there any examples around showing that?

The special collections? I don't know much because most of the time you don't need something special. The only thing that comes to my mind are the reduced conflict collection classes in gemstone that could be considered special. But basically you subclass a collection class that deals with a special implementation and then you just create that one instead to other.

>>
>> - In SQL databases the instance variables are mapped to columns of a
>> table or multiple tables and each row is an object. Relationships of
>> objects are handled by keys in the tables. A 1:1 relationships
>> contains a key of the relation source in the relation target table. A
>> n:m relationship needs an intermediate table that maps relation source
>> keys to relation target keys. Talking about inheritance this gets
>> easily complicated. Basically there are two options. You can solve it
>> like everyone would expect it, let's say more BNF like. You would have
>> a table A for class A and a table B for class B. Now in all tables of
>> objects that reference A or B you need an additional information which
>> class is meant: A or B. The tables than could be joint correctly after
>> evaluation the additional value. Another strategy is to do multiple
>> lookups until you've found the right value. The other approach is to
>> make one table that is a super set of all needed variables. The keys
>> are unique among all the subclasses and can be lookuped up more
>> easily. But you waste some space because a lot of the columns would be
>> empty. In any case you need to change your database schema if you
>> change your model. Joins and number of requests can grow easily so
>> that your application will be slowed down. Glorp gives you all of
>> these strategies if you want them. My personal advize would be to
>> avoid inheritance in that scenario completely or do only the simplest
>> cases possible. Relational databases and object oriented approaches
>> just don't fit together.
> Well that was what liked to get shown. I was thinking in the simples
> possible cases of inheritance and how "bad/good" that works with RDBs.
>
> So I wanted to know if someone has done some work on ORM to handle that
> with not too much pain on "my side".
>

Define pain! :) I used Glorp a lot and is good piece of software. It helps you a lot with these things. Well, it helps you as much as it is possible when dealing with RDBs. I could create most of the cases but then suddenly a login attempt to the website caused around 400 requests to the database just to show the first page. That's the point where it turns against you and you have trouble to look behind all that that was causing you less pain.

> I expected something like that. Either you build you stuff that it fits
> the RDB model  or you better avoid RDBs. I have tried  to  figure
> that out e.g in Rails but it all comes short if  "even" simple
> inheritance comes into play. You message just confirms this impression.
>
I think this is a more general rule. Things are made for a purpose. If you try to force them to fulfill a completely different purpose it probably won't work out. At least it will cause you pain.

> Any way my question still  persists,  are there anywhere examples on
> handling inheritance in ORMs?

I scanned my old archives but didn't find a good example at first glance. Maybe it is not in my repository because all the attempts weren't satisfactory at all. So I probably never committed one of the trials.

Norbert
_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Someone with Gemstone Experiences?

FDominicus
In reply to this post by Stéphane Ducasse
Is there anyone near Karlsruhe,  Mannheim, Heidelberg who could spend
some time introducing mit to GemStone?

Thanks
Friedrich


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

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Someone with Gemstone Experiences?

Stéphane Ducasse
HI freidrich

do you want me to forward this mail to esug?

Stef
On Apr 12, 2010, at 11:18 AM, Friedrich Dominicus wrote:

> Is there anyone near Karlsruhe,  Mannheim, Heidelberg who could spend
> some time introducing mit to GemStone?
>
> Thanks
> Friedrich
>
>
> --
> Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
> Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users