Experiences with non RDBs?
Locked
 
|
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 |
|
|
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 > 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 |
Re: Experiences with non RDBs?
|
|
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 |
|
|
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 |
Re: Experiences with non RDBs?
|
|
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 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 _______________________________________________ Pharo-users mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users |
|
|
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 |
|
|
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 |
|
|
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 |
Re: Experiences with non RDBs?
|
|
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 |
|
|
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 > > - 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. 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 |
|
|
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 |
Someone with Gemstone Experiences?
|
|
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 |
Re: Someone with Gemstone Experiences?
|
|
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 |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |