databases
Locked
12
12
 
|
Dear All,
We've also created a (little) project that uses Magma: We've noticed, if you cache the correct things, Magma is single user very fast; but also highly scalable (ha options + the number of items it can hold in a collection).
Once the initial setUp was done, adding new behaviour on our domain objects took no effort. No effort at all. It just got saved ... Kind Regards, Bart 2010/2/17 laurent laffont <[hidden email]>
-- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Matthias Berth-2
I like the idea that you do not have to change your root class superclass to get it saved.
Stef On Feb 17, 2010, at 9:08 PM, Matthias Berth wrote: > Laurent, > > you might want to have a look at SqueakSave > > http://www.hpi.uni-potsdam.de/hirschfeld/projects/squeaksave/index.html > > an object-relational (O/R) mapping framework. It looks similar to the > rails ActiveRecord framework (from what I have seen so far) so it > might be fine in scenarios where you absolutely want a relational > database. > > A bit older: > > http://video.google.com/videoplay?docid=-5024583807516452190&hl=en# > > 2010/2/17 laurent laffont <[hidden email]>: >> Hi, >> I would like to learn on Pharo + databases. I've seen there's several >> solutions in both object and relational databases. >> - Which (open source) object database should I start with (most used) ? >> - Which object database can be accessed from Smalltalk AND Ruby or Python ? >> How ? >> - I want to try MySQL too. >> Is there up to date small applications on squeaksource which show this stuff >> quite well ? >> Thanks for help ! >> Laurent Laffont >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by csrabak
we are working on setting up a pier book so that you guys can structure this information in a nice way.
On Feb 18, 2010, at 12:43 AM, [hidden email] wrote: > All those interesting pieces of information about what works and what does not is very valuable. > > Is there a means of having a place in Pharo Wiki where we could publish and update this? > > -- > Cesar Rabak > > > Em 17/02/2010 13:05, Germán Arduino < [hidden email] > escreveu: > > > > 2010/2/17 Dave Woodward <[hidden email]> > > > > > On 2/17/10 6:46 AM, Germán Arduino wrote: > > > > 2010/2/17 laurent laffont <[hidden email]> > > Hi, > > I would like to learn on Pharo + databases. I've seen there's several solutions in both object and relational databases. > - Which (open source) object database should I start with (most used) ? > > > > Magma is the option I select, but not tried yet on Pharo. > > > > > Magma 1.0v43 works on Pharo, > > > > Good to know. > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by laurent laffont
On Wed, 17 Feb 2010, laurent laffont wrote:
> Really great informations : > Scenario˙˙s > > In different situations, there are different storage needs > > 1. You are writing a small demonstration program to show your customers, > and want to populate the system with some representative data. Add a class > instance variable to store the instances, and simply save the image. > 2. You have a small system with a few hundred/thousand objects, and are > not dependent on external systems. A prevayler-like system like SandstoneDB > might be a perfect fit. Each object save means a disk access, so scaling > ends with disk speed. A few old versions of the data are kept around, so > backing up or reverting is easy. If you want a readable representation, SIXX > might help. > 3. You have a legacy (relational) database, with extensive reporting > written for it. Use an ORM. key-value stores don't (and won't). ORMs may ease the programmer's work, but they tend to have bad runtime performance and can't use (all) the features of todays RDBMSs. Levente > 4. You have a complex and large object model that has to support changing > the object model while developing. The solution is an OODB. Gemstone is the > large and proven commercial offering. It has a free version for smaller > databases (4GB data, 1 core, 1G ram), and has proven scalability to 500 > machines. Magma is an open source OODB, seeing active development and > growing more and more advanced functionality. > > > > Laurent Laffont > > > On Wed, Feb 17, 2010 at 3:07 PM, laurent laffont > <[hidden email]>wrote: > >> No :) Thanks for the link ! >> >> Laurent Laffont >> >> >> >> On Wed, Feb 17, 2010 at 2:23 PM, Stephan Eggermont <[hidden email]>wrote: >> >>> Hello Laurent, >>> >>> I assume you are aware of: >>> >>> http://www.seaside.st/documentation/persistence >>> >>> Stephan >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> > Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
El jue, 18-02-2010 a las 16:51 +0100, Levente Uzonyi escribió:
> On Wed, 17 Feb 2010, laurent laffont wrote: > > > Really great informations : > > Scenario˙˙s > > > > In different situations, there are different storage needs > > > > 1. You are writing a small demonstration program to show your customers, > > and want to populate the system with some representative data. Add a class > > instance variable to store the instances, and simply save the image. > > 2. You have a small system with a few hundred/thousand objects, and are > > not dependent on external systems. A prevayler-like system like SandstoneDB > > might be a perfect fit. Each object save means a disk access, so scaling > > ends with disk speed. A few old versions of the data are kept around, so > > backing up or reverting is easy. If you want a readable representation, SIXX > > might help. > > 3. You have a legacy (relational) database, with extensive reporting > > written for it. Use an ORM. > > Relational databases are not legacy, they have features which "modern" > key-value stores don't (and won't). I don't think he is refering to RDBMS as legacy, as we know that they aren't. I think that he meant that when you have a fully populated database (legacy) and you are building a new seaside/pharo application to exploit that data, the best is to use an ORM for simple querys and direct querys for complex ones. > ORMs may ease the programmer's work, > but they tend to have bad runtime performance and can't use (all) the > features of todays RDBMSs. That is true but also the right thing, it isn't expected that an ORM standardize a way to backup a database, partition a table, replication, node management, user sessions and transaction monitoring, change index types and in general everything that is considered metadata or simply database administration. An ORM is for user stuff querys, insertions, deletion, etc. Cheers > > > Levente > > > 4. You have a complex and large object model that has to support changing > > the object model while developing. The solution is an OODB. Gemstone is the > > large and proven commercial offering. It has a free version for smaller > > databases (4GB data, 1 core, 1G ram), and has proven scalability to 500 > > machines. Magma is an open source OODB, seeing active development and > > growing more and more advanced functionality. > > > > > > > > Laurent Laffont > > > > > > On Wed, Feb 17, 2010 at 3:07 PM, laurent laffont > > <[hidden email]>wrote: > > > >> No :) Thanks for the link ! > >> > >> Laurent Laffont > >> > >> > >> > >> On Wed, Feb 17, 2010 at 2:23 PM, Stephan Eggermont <[hidden email]>wrote: > >> > >>> Hello Laurent, > >>> > >>> I assume you are aware of: > >>> > >>> http://www.seaside.st/documentation/persistence > >>> > >>> Stephan > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> [hidden email] > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >> > >> > > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by laurent laffont
Hi Laurent. I agree with you. From my point of view, there are a lot of persistence strategies and possibilities. But the problem I faced most of the time is that you are not able to choose. It is not common you can choose the database and even more the database. At least in real business or company applications. Thee are a LOT of reason, logical and not logical. If you want I can share with you the reasons I found so far. If you can choose, I would probably use a OO database. Magma or GLASS are the better solutions for me. There is also GOODS but I heard bad comments from a friends that are using it at their work. Then you have all those "non traditional" databases like Toyko, CouchDB, MongoDB, etc. You can give them a try. You have also serializers like SIXX, ImageSegments, SmartRefStream, save in the image, etc. This can be a solution for very limited for my opinion (small apps). However, they are very useful when starting a project or even for prototyping. Finally, you may HAVE or you want to use relational database. First, which database? most of the time, you cannot choose. For Pharo, there seems to be native drivers for PostgreSQL and MySQL. The first one is working on Pharo. The second one I don't know. SQLite driver I think it is not native (maybe I am wrong...). We did SqueakDBX where you can talk with Oracle, MSSQL, MySQL, PostgreSQL, Sqlite3, Firebird (only windows) and ODBC in all OS (Linux, Mac Os and Windows). After the "driver layer" then you have Glorp and SqueakSave mostly. Glorp is much powerful and complete. But, the Pharo/Squeak version is quite old as Glorp is developed in VW. The "problem" with Glorp is that you have to write all the queries by hand. If you want to use other that PostgreSQL with Glorp in Pharo then you need to install GlorpDBX. You can SandstoneDB if you want and then you also have Glorp-ActiveRecord, but only VW (as it is new, it is not ported to squeak or pharo). In those approaches, the time of developing is less as you don't have to write all the mappings. Finally, with SqueakSave you can automatically persist. It takes care of writing everything. You don't need to write the mappings. Of course, you need to follow certain conventions in the names. SqueakSave supports MySQL and PostgreSQL only althought they wanted to interface with SqueakDBX to support all databases. I don't know neither if it works on Pharo. Of course, it seems to be a less slower than Glorp as the queries are not the faster. If I were you, for the screencast, I would really like to see the following scenario: you have a domain model and then you persists: 1) Image based / serializers (sixx, ImageSegments, SmartRefStream, etc) 2) OO database -> magma or GLASS 3) Relational database -> Glorp, SqueakSave, etc Each item can be a different post and for each item you show the advantages or disadvantages and of course, in each item, the domain model is the same. Of course this may require a lot of time and effort :) Uffff now I realized this is almost the same Torsted said. Sorry. Cheers Mariano 2010/2/17 laurent laffont <[hidden email]> Hi, _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Thank you very much Mariano.
Now I can choose because Pharo is still a hobby for me ;) I've started learning Magma, it's fun, so easy .... Laurent Laffont 2010/2/18 Mariano Martinez Peck <[hidden email]>
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Chris Muller-3
Hi!
Chris Muller wrote: > Hi Göran, since this is at least the second time you've indicated > having a performance issue with Magma, I'd like to reiterate my offer > of assistance. Thanks. :) > I know it takes time to evaluate other persistence options, so I would > be surprised if you've already started off in another direction merely > because you thought nothing could be done. Indeed, and you even > indicated optimism that the slowness can probably be fixed. Given my > limited knowledge of Gjaller, it seems to me that Magma should be a > perfect fit for it, especially in terms of performance and > scalability. > > My own curiousity is brimming, you are having a performance issue, > there are many many opportunities for optimization, wouldn't you like > to talk about it? Sure, my problem is that I have a general lack of time. But I intend to try to take a serious look soon. I presume that strategies in combination with running with external server might help "enough". Getting a session takes time, I have written a second "preallocated session queue" to remove that issue, and it seems to work ok. It was a long time since I worked on this, so I don't have more details at hand right now. I need to start by rebasing on newest Magma. regards, Göran _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Levente Uzonyi-2
Em 18/02/2010 13:51, Levente Uzonyi < [hidden email] > escreveu:
> On Wed, 17 Feb 2010, laurent laffont wrote: [snipped] > > 3. You have a legacy (relational) database, with extensive > > reporting written for it. Use an ORM. > Relational databases are not legacy, they have features which > "modern" key-value stores don't (and won't). ORMs may ease the > programmer's work, but they tend to have bad runtime performance and > can't use (all) the features of todays RDBMSs. > Levente, I think the advice doesn't intend to imply that RDBMSs are legacy _technology_. What I understand from the text is understanding the existence of an application (or a lot of data) already using a RDBMS, and so it is legacy for the programmer with the task at hand. OTOH, if we take the features of the RDBMS is central to task at hand, (and not available to Pharo) or ORM makes performance unacceptable then it may end that Pharo should not contemplated to start with, so the point becomes moot. . . just my 0.019999.... -- Cesar Rabak _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by laurent laffont
Levente wrote in response to my:
>> 3. You have a legacy (relational) database, with extensive reporting >> written for it. Use an ORM. >Relational databases are not legacy, they have features >which "modern" key-value stores don't (and won't). >ORMs may ease the programmer's work, but they >tend to have bad runtime performance >and can't use (all) the features of todays RDBMSs. In creating the list of different scenarios, I tried to explain in a short text that different needs lead to different solution strategies. Legacy in this context refers to having an existing database you want to continue using. That is a situation where I would recommend starting with ORM unless it is shown that the run-time performance is going to be prohibitive. Please keep in mind that it is a text written for people new to Seaside (and possibly Smalltalk). If you have a suggestion for a better text, please mail me. Stephan Eggermont _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
SqueakSave on Pharo (was: databases)
|
|
In reply to this post by Mariano Martinez Peck
Mariano Martinez Peck wrote:
> Finally, with SqueakSave you can automatically persist. It takes care of > writing everything. You don't need to write the mappings. Of course, you > need to follow certain conventions in the names. SqueakSave supports > MySQL and PostgreSQL only althought they wanted to interface with > SqueakDBX to support all databases. I don't know neither if it works on > Pharo. Of course, it seems to be a less slower than Glorp as the queries > are not the faster. I have a tweaked version that loads into Pharo. I had to open up the .mcz and edit the source.st to get the first version loaded. The test cases were only set up to run against MySQL, but I've adjusted it for Postgres. I can't remember offhand whether I got all the tests to pass, but I think only a handful were still failing due to MySql vs. Postgres issues. The original repository from HPI seems to be offline now (and a few weeks ago). I've not seen any community of users, and I'm not sure what development is ongoing. I can make my .mcz available if someone wants it. -- Yanni _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: SqueakSave on Pharo (was: databases)
|
|
On Fri, Feb 19, 2010 at 6:19 PM, Yanni Chiu <[hidden email]> wrote: Mariano Martinez Peck wrote:
Can you put it on squeaksource ? Laurent Laffont _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
laurent laffont wrote:
> The original repository from HPI seems to be offline now (and a few > weeks ago). I've not seen any community of users, and I'm not sure what > development is ongoing. I can make my .mcz available if someone > wants it. > > > > Can you put it on squeaksource ? I'll clean up the package I have, and then ping the author for how contributions are to be handled (before forking it on squeaksource). BTW, the HPI repository is now back online. -- Yanni _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Fri, Feb 19, 2010 at 9:24 PM, Yanni Chiu <[hidden email]> wrote: laurent laffont wrote: Great ! Laurent Laffont
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: SqueakSave on Pharo (was: databases)
|
|
In reply to this post by Yanni Chiu
On Fri, Feb 19, 2010 at 6:19 PM, Yanni Chiu <[hidden email]> wrote: Mariano Martinez Peck wrote: This is excellent. I think having SqueakSave working on pharo is a cool thing. If there are differences between squeak, remember a Metacello configuration can help. Please, keep us informed about the progress. Cheers Mariano I had to open up the _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by laurent laffont
laurent laffont wrote:
> On Fri, Feb 19, 2010 at 9:24 PM, Yanni Chiu > > > > Can you put it on squeaksource ? > > I'll clean up the package I have, and then ping the author for how > contributions are to be handled (before forking it on squeaksource). > BTW, the HPI repository is now back online. Okay, it's at: http://www.squeaksource.com/SqueakSave SqSave-tkow.127.mcz - This version was created from the HPI version by unzip'ing the .mcz, fixing the issues that prevented it from loading into Pharo, by editing the source.st file, then re-zip'ing into a .mcz package. SqSave-YanniChiu.135.mcz - This version was developed for my needs at the time, then clean up somewhat for public release. Using the native postgres driver (and probably dbx one too), the following 3 tests are still failing: >>> SqsCTISearchQueryTest.testQueryBlob >>> SqsCTISearchQueryTest.testReferenceToSubclassElementWithinCollection >>> SqsSTISearchQueryTest.testQueryBlob Some class category names were changed, and some example code left out. The original .127.mcz should be loadable, so you can see what was changed. The repository is set for global read/write. -- Yanni _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Yanni excellent to have it on squeaksource.
Now did you contact the maintainer (if any) or the people that developed it (I like it a lot) to mention that? Because at least they should know if some changes get introduced that they can cherrypick it. Stef On Feb 28, 2010, at 2:49 AM, Yanni Chiu wrote: > laurent laffont wrote: >> On Fri, Feb 19, 2010 at 9:24 PM, Yanni Chiu >>> >>> Can you put it on squeaksource ? >> >> I'll clean up the package I have, and then ping the author for how >> contributions are to be handled (before forking it on squeaksource). >> BTW, the HPI repository is now back online. > > Okay, it's at: > > http://www.squeaksource.com/SqueakSave > > SqSave-tkow.127.mcz - This version was created from the HPI version by > unzip'ing the .mcz, fixing the issues that prevented it from loading > into Pharo, by editing the source.st file, then re-zip'ing into a .mcz > package. > > SqSave-YanniChiu.135.mcz - This version was developed for my needs at > the time, then clean up somewhat for public release. Using the native > postgres driver (and probably dbx one too), the following 3 tests are > still failing: > >>>> SqsCTISearchQueryTest.testQueryBlob >>>> SqsCTISearchQueryTest.testReferenceToSubclassElementWithinCollection >>>> SqsSTISearchQueryTest.testQueryBlob > > > Some class category names were changed, and some example code left out. > The original .127.mcz should be loadable, so you can see what was > changed. The repository is set for global read/write. > > -- > Yanni > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I sent an email last week, and saw no answer, so far. So I've put up
what I have. Stéphane Ducasse wrote: > Yanni excellent to have it on squeaksource. > Now did you contact the maintainer (if any) or the people that developed it (I like it a lot) to mention that? > Because at least they should know if some changes get introduced that they can cherrypick it. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: SqueakSave on Pharo
|
|
In reply to this post by Yanni Chiu
On Sun, Feb 28, 2010 at 2:49 AM, Yanni Chiu <[hidden email]> wrote:
the dbx will work with Blob ONLY in the latests commits...as I have been playing with that few weeks ago. still failing: _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |