About SToR
Locked
 
|
>> I was wondering if it would not make a lot of sense to have a
>> small framework called STOR that mimic (especially the persistency >> part of RoR) in seaside and magritte. >> It seems to me that lot of people are doing simple application and >> that the persistance is really important there. >> What do you think about that? _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
I've been doing some Rails work lately. ActiveRecord is really nice,
and Migrations are fantastic. Porting ActiveRecord to squeak and providing browser support for it seems like a slam dunk to me. I wouldn't do a straight port but just borough the main concepts. On 7/28/06, stephane ducasse <[hidden email]> wrote: > >> I was wondering if it would not make a lot of sense to have a > >> small framework called STOR that mimic (especially the persistency > >> part of RoR) in seaside and magritte. > >> It seems to me that lot of people are doing simple application and > >> that the persistance is really important there. > >> What do you think about that? > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by stephane ducasse
There was some discussion about ActiveRecord-like functionality
on the list a little over a year ago: http://lists.squeakfoundation.org/pipermail/seaside/2005-April/004751.ht ml In that discussion, Avi Bryant indicated that there is a Smalltalk framework called ReStore: http://www.solutionsoft.co.uk/restore/ that is similar to ActiveRecord, but it is only available for Dolphin Smalltalk. It might be interesting to see if the people behind ReStore would be interested in a port to Squeak, especially now Seaside has been ported to Dolphin. ----------=-=-=-=-=-=-=-=-========oOo========-=-=-=-=-=-=-=-=---------- mailto:[hidden email] Phone:(607)770-3701 CSC @ BAE SYSTEMS 600 Main St Johnson City, NY 13790-1888 ----------=-=-=-=-=-=-=-=-===================-=-=-=-=-=-=-=-=---------- -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of stephane ducasse Sent: Friday, July 28, 2006 3:54 AM To: The Squeak Enterprise Aubergines Server - general discussion. Subject: [Seaside] About SToR >> I was wondering if it would not make a lot of sense to have a >> small framework called STOR that mimic (especially the persistency >> part of RoR) in seaside and magritte. >> It seems to me that lot of people are doing simple application and >> that the persistance is really important there. >> What do you think about that? _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by wilkesj
On 7/28/06, Wilkes Joiner <[hidden email]> wrote:
I've been doing some Rails work lately. ActiveRecord is really nice, I'm still not convinced this is a good idea. ActiveRecord is trying to solve a simple problem at its base: how can we persist massive collections of objects in Ruby? The answer they arrived at was to use an RDBMS for persistence, and then to adopt the same translation concept as a dozen other frameworks have tried: tables to classes, rows to objects, columns to instance variables. The problem is that this mapping does not make sense. It breaks the object model in subtle and not-so-subtle ways that ultimately become extraordinarily aggravating. There are whole concepts easily expressed in OO that are painfully expressed in RDBMSes at best. Trees, custom data-structures, even the whole concept of subclasses. Some of these can be worked around--recursive queries in SQL 3 permit trees, most databases let you add new data-structure by writing libraries in C, and subclasses usually can be expressed through a mix of normalizing and repeating columns across tables--but it requires effor that could be spent on getting things done, rather than simply figuring out how to persist data. Even Rails' migrations are a great example of a problem that RDBMSes have that Squeak does not have to have. It's basically a version-control system for the database. In Squeak, youcould simply use Monticello combined with giving your class lazy initialization. Migrations are a band-aid over the fact that relational models can't or don't express these concepts. Rather than try to graft objects on top of the database, I greatly prefer the idea started with ROE of bringing relational algebra to Squeak. ROE lets you cleanly write relational queries within Squeak without resorting to SQL, but deliberately makes no other attempt to unify the object and relational worlds. Though I admit this is a slightly more Lisp-like solution, I also strongly believe that it's the correct one. If you're writing a new application, though, why use an RDBMS in the first place? Why not figure out a way to truly persist objects? This is the solution I would like to see more Squeak users adopt. We already have two OODBMSes that we can reasonably use: GOODS, which is fast and well-tested, and Magma, which is slow but gradually improving. Rather than spending time vainly trying to get objects mapping to relational models, I'd rather spend time improving our object databases until they become truly optimal solutions for a wider class of problems. Having said all of that, I do understand the need for an object-relational mapper for legacy applications, but ActiveRecord is a bad model to follow for a solution. ActiveRecord achieves its simplicity by strongly encouraging the development of database schemas in a very particular way, and although it is slowly gaining the flexibility to deal with schemas that do not follow its preferred convention, there are many other frameworks--WebObject's Enterprise Objects Framework being my favorite--that are much better examples of legacy interfaces, if that's the route you wish to go. I do think it would be wonderful if Seaside had a built-in persistence mechanism as easily usable as Rails, but I would hope that the solution it ends up adopting is not ActiveRecord. --Benjamin _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Benjamin Pollack wrote:
> On 7/28/06, Wilkes Joiner <[hidden email]> wrote: >> >> I've been doing some Rails work lately. ActiveRecord is really nice, >> and Migrations are fantastic. Porting ActiveRecord to squeak and >> providing browser support for it seems like a slam dunk to me. I >> wouldn't do a straight port but just borough the main concepts. > > I'm still not convinced this is a good idea. > > ActiveRecord is trying to solve a simple problem at its base: how can we > persist massive collections of objects in Ruby? The answer they arrived at > was to use an RDBMS for persistence, and then to adopt the same translation > concept as a dozen other frameworks have tried: tables to classes, rows to > objects, columns to instance variables. The problem is that this mapping > does > not make sense. It breaks the object model in subtle and not-so-subtle ways > that ultimately become extraordinarily aggravating. > > There are whole concepts easily expressed in OO that are painfully > expressed > in RDBMSes at best. Trees, custom data-structures, even the whole > concept of > subclasses. Treating an RDBMS as an object persistence store does indeed cause problems. At the core is the fact that an RDBMS is about data and objects are about behaviour. The RDBMS is supposed to be an application-neutral store of relevant business-related facts, whereas your objects are (hopefully) structured in a manner that is convenient for your application. For myself I've been working at things from the other direction. Object-oriented systems are good at modelling things, so I've been building a model of the database. A proper one, not ActiveRecord. I have classes to model the DB, relation defintions, relations themselves (whether a whole table or query results), attributes, attribute types, default values, foreign-keys, multi-column primary keys etc. With a little meta-data from the comments in the DB (I'm working with PostgreSQL) it knows the human-readable names of tables, views, attributes etc. Oh, and which attribute(s) can be used to describe a particular row (e.g. first_name, last_name). Tuples have a concept of old and new values, so you can have validation on individual attributes or the tuple as a whole. Oh, and attributes are accessed by name (myTuple at: 'id') not as separate member functions. I still have a fair bit of work to do with constraints, and to automatically generate the definitions from my database parser (in Perl). Then, I need to have a proper look at ROE and see what I can steal^W integrate from that - the querying looks very nice. Would anyone else be interested in this if I can get the time to tidy it up and make it presentable? -- Richard Huxton Archonet Ltd _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Benjamin Pollack
On Jul 28, 2006, at 11:17 AM, Benjamin Pollack wrote: On 7/28/06, Wilkes Joiner <[hidden email]> wrote: Having wrestled with this problem before, I'll add a data point to each side here: For those show want to store objects in a relational database, Tantalus might be worth a look. It's probably not usable off the shelf, as it was written for Squeak 3.2, but it might provide a ideas and code for some new framework. On the other hand, I have to agree with Benjamin. Storing objects as rows works reasonably well for simple cases, but it breaks down awfully quickly when your object models start to get more complex than collections. On top of that, there's another, more subtle mismatch when Seaside is involved. Seaside wants objects to have long lifecycles. It tends to hang on to objects in component instance variables, link and form callbacks, and session-wide state. Even "temporary" variables tend to live a long time, since continuations can be retrieved and reentered minutes or hours after they were captured. Databases, on the other hand want transactions to be short. "Long transactions" are a classic problem to avoid in the database world. This means that the O/R mapping layer has to be very careful about caching, managing the state of persistent objects, and detecting conflicts. It gets really tricky when you have Seaside trying to keep objects in sync with the browser on the front end, and the persistence layer trying to keep them in sync with the database on the back end. All this is not to say that O/R mapping can't be done, but I think it's almost impossible to do it in a way that's general enough for a wide range of applications, yet seamless and transparent for the developer. The only place I've seen it work well was when it was not transparent at all, but built in to the application and carefully crafted to have the behavior required by the application. Colin _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by wilkesj
> -----Original Message-----
> From: [hidden email] > [mailto:[hidden email]] On Behalf > Of Wilkes Joiner > Sent: Friday, July 28, 2006 6:33 AM > To: The Squeak Enterprise Aubergines Server - general discussion. > Subject: Re: [Seaside] About SToR > > I've been doing some Rails work lately. ActiveRecord is > really nice, and Migrations are fantastic. Porting > ActiveRecord to squeak and providing browser support for it > seems like a slam dunk to me. I wouldn't do a straight port > but just borough the main concepts. ActiveRecord is nothing more than a simplified object relational mapper, Squeak already has two of those, Glorp and Tantalus, better to look at those and see what would be needed to wrap it up into something automatic and easy to use, than to reinvent the wheel. Tantalus especially, is very similar in it's assumptions about the schema as ActiveRecord. Secondly, this isn't "the" big problem that needs solved, Squeaks big problem is its lack of native bindings to the big two enterprise databases, SqlServer and Oracle. Currently these have to be accessed via ODBC which doesn't scale because it blocks the VM due to its use of FFI. And blocking the VM in a web app that's inherently multithreaded just isn't acceptable. I think this is what prevents it from gaining wider acceptance, and will continue to be it's Achilles heel. MySql and Postgres aren't really options, as they aren't widely used in the enterprise, why Squeak has better bindings for those is beyond me. That leaves Squeak with very poor relational database support, which brings us to object databases. Magma and Goods, both good solid ODB's from my understanding, I use Goods personally, Magma's still under active development and I feel safer with Goods, however, using an ODB isn't particularly easy when one is accustomed to relational databases. Not being able to just write a query and search a bunch of objects is a big hurdle, you have to think things out ahead of time and create indexes by hand to get any decent speed from the system, and there's really very little out there to guide one in learning all this stuff, frankly it's a painful process, one I'm still in the midst of figuring out myself as I bring Squeak and Seaside into the office. I've felt enough pain mapping objects into relational database that I've also come to believe object databases are the way to go when dealing with object oriented applications. Maybe things are more advanced in a more enterprise Smalltalk like VisualWorks or Gemstone, I hope so, because the state of the object databases in squeak at the moment seems quite alpha, and still a bit too painful to be able to easily replace a relational database for most apps. I think if the community wants newcomers to stop wishing for ActiveRecord, and relational support in general, there needs to be much more discussion on this list about how to use object databases, how to do full text searching, and how to index objects efficiently, because like it or not, most people who approach Seaside, almost immediately, are going to start wondering about persistence. Rails took off in part due to it's slick integration of persistence into it's web framework. As cool as Seaside is, without a reliable and simple means of persistence, few will find use for it. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by stephane ducasse
Others have given very good reasons not to do this: existing OR
mapping layers, object-databases, problems with mapping complex objects structures to relational databases, problems with continuations holding objects, etc. I am not arguing against these. But while I have been doing some web development I have not used Seaside for a long time :(. I have been using Django. It has a simple OR layer, with all the problems others have mentioned. I have to deal with Python, which I am not very fond of, crummy environments, poor IDEs, no interactive debugging, etc. All the while wishing I was using Seaside. But I use Django because once I define my "object models" (really just simple OR mappings - talk about a mixed up object model) Django generates the database tables and an administration site to enter data and manage users, which saves time. For simple projects I am more than 1/2 done at this point. Most of the stuff I have been doing is simple enough that the problems people mention are not an issue. Of course except for one project that looks like it may push the boundary on what is easy to do in Django. So do I rewrite the app in Seaside? Well at this point I have already invested time in the Django, is it worth switching? These frameworks take some effort to master. Just look at all the questions on this list about how to do X in Seaside. The details of Django are fresh in my head, details of using Seaside are not so fresh. It would take sometime to become proficient again partially offsetting Seaside's advantages. So as a result Seaside looses mind share. I think what Stephane is saying we should try to make it easy for people to do simple things in Seaside so we can gain some mind share. On Jul 28, 2006, at 12:54 AM, stephane ducasse wrote: >>> I was wondering if it would not make a lot of sense to have a >>> small framework called STOR that mimic (especially the >>> persistency part of RoR) in seaside and magritte. >>> It seems to me that lot of people are doing simple application >>> and that the persistance is really important there. >>> What do you think about that? > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > ---- Roger Whitney Department of Computer Science [hidden email] San Diego State University http://www.eli.sdsu.edu/ San Diego, CA 92182-7720 (619) 583-1978 (619) 594-3535 (office) (619) 594-6746 (fax) _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
I thought Kilauea was suppose to address this small web app in one
package sweetspot. Rodger, perhaps a small test app would let you know if Seaside dev is sweet enough for an old Smalltaker as yourself. (I think it has legs.) It has several working examples in its default image. Play with it a little. Check out the scriptaculous version. On 7/28/06, Roger Whitney <[hidden email]> wrote: > Others have given very good reasons not to do this: existing OR > mapping layers, object-databases, problems with mapping complex > objects structures to relational databases, problems with > continuations holding objects, etc. I am not arguing against these. > > But while I have been doing some web development I have not used > Seaside for a long time :(. I have been using Django. It has a simple > OR layer, with all the problems others have mentioned. I have to deal > with Python, which I am not very fond of, crummy environments, poor > IDEs, no interactive debugging, etc. All the while wishing I was > using Seaside. But I use Django because once I define my "object > models" (really just simple OR mappings - talk about a mixed up > object model) Django generates the database tables and an > administration site to enter data and manage users, which saves time. > For simple projects I am more than 1/2 done at this point. Most of > the stuff I have been doing is simple enough that the problems people > mention are not an issue. > > Of course except for one project that looks like it may push the > boundary on what is easy to do in Django. So do I rewrite the app in > Seaside? Well at this point I have already invested time in the > Django, is it worth switching? These frameworks take some effort to > master. Just look at all the questions on this list about how to do X > in Seaside. The details of Django are fresh in my head, details of > using Seaside are not so fresh. It would take sometime to become > proficient again partially offsetting Seaside's advantages. So as a > result Seaside looses mind share. I think what Stephane is saying we > should try to make it easy for people to do simple things in Seaside > so we can gain some mind share. > > On Jul 28, 2006, at 12:54 AM, stephane ducasse wrote: > > >>> I was wondering if it would not make a lot of sense to have a > >>> small framework called STOR that mimic (especially the > >>> persistency part of RoR) in seaside and magritte. > >>> It seems to me that lot of people are doing simple application > >>> and that the persistance is really important there. > >>> What do you think about that? > > _______________________________________________ > > Seaside mailing list > > [hidden email] > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > > ---- > Roger Whitney Department of Computer Science > [hidden email] San Diego State University > http://www.eli.sdsu.edu/ San Diego, CA 92182-7720 > (619) 583-1978 > (619) 594-3535 (office) > (619) 594-6746 (fax) > > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by stephane ducasse
I should just tell you the context of this idea:
It seems to me that there is market that we miss: simple web application development. Seaside is cool for complex flow ones. But why can we have something really simple to define a domain (ie my comix collection) and that we can edit, sort, ... + store in a stupid DB. Stef On 28 juil. 06, at 09:54, stephane ducasse wrote: >>> I was wondering if it would not make a lot of sense to have a >>> small framework called STOR that mimic (especially the >>> persistency part of RoR) in seaside and magritte. >>> It seems to me that lot of people are doing simple application >>> and that the persistance is really important there. >>> What do you think about that? > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Ramon Leon-5
> I think if the community wants newcomers to stop wishing for > ActiveRecord, > and relational support in general, there needs to be much more > discussion on > this list about how to use object databases, how to do full text > searching, > and how to index objects efficiently, because like it or not, most > people > who approach Seaside, almost immediately, are going to start > wondering about > persistence. Rails took off in part due to it's slick integration of > persistence into it's web framework. As cool as Seaside is, without a > reliable and simple means of persistence, few will find use for it. This was my point, even if after for complex objects this is painful. Entry level should be simpler. Stef _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Roger Whitney
Hi roger
I would really to know your experience with seaside for the same kind of problem. And also I would love to know what should be done to get a "django" for Squeak. Stef On 28 juil. 06, at 21:36, Roger Whitney wrote: > Others have given very good reasons not to do this: existing OR > mapping layers, object-databases, problems with mapping complex > objects structures to relational databases, problems with > continuations holding objects, etc. I am not arguing against these. > > But while I have been doing some web development I have not used > Seaside for a long time :(. I have been using Django. It has a > simple OR layer, with all the problems others have mentioned. I > have to deal with Python, which I am not very fond of, crummy > environments, poor IDEs, no interactive debugging, etc. All the > while wishing I was using Seaside. But I use Django because once I > define my "object models" (really just simple OR mappings - talk > about a mixed up object model) Django generates the database tables > and an administration site to enter data and manage users, which > saves time. For simple projects I am more than 1/2 done at this > point. Most of the stuff I have been doing is simple enough that > the problems people mention are not an issue. > > Of course except for one project that looks like it may push the > boundary on what is easy to do in Django. So do I rewrite the app > in Seaside? Well at this point I have already invested time in the > Django, is it worth switching? These frameworks take some effort to > master. Just look at all the questions on this list about how to do > X in Seaside. The details of Django are fresh in my head, details > of using Seaside are not so fresh. It would take sometime to become > proficient again partially offsetting Seaside's advantages. So as a > result Seaside looses mind share. I think what Stephane is saying > we should try to make it easy for people to do simple things in > Seaside so we can gain some mind share. > > On Jul 28, 2006, at 12:54 AM, stephane ducasse wrote: > >>>> I was wondering if it would not make a lot of sense to have a >>>> small framework called STOR that mimic (especially the >>>> persistency part of RoR) in seaside and magritte. >>>> It seems to me that lot of people are doing simple application >>>> and that the persistance is really important there. >>>> What do you think about that? >> _______________________________________________ >> Seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > > ---- > Roger Whitney Department of Computer Science > [hidden email] San Diego State University > http://www.eli.sdsu.edu/ San Diego, CA 92182-7720 > (619) 583-1978 > (619) 594-3535 (office) > (619) 594-6746 (fax) > > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Ramon Leon-5
Hi folks!
"Ramon Leon" <[hidden email]> wrote: > That leaves Squeak with very poor relational database support, which brings > us to object databases. Magma and Goods, both good solid ODB's from my > understanding, I use Goods personally, Magma's still under active > development and I feel safer with Goods, however, using an ODB isn't > particularly easy when one is accustomed to relational databases. Not being > able to just write a query and search a bunch of objects is a big hurdle, > you have to think things out ahead of time and create indexes by hand to get > any decent speed from the system, and there's really very little out there > to guide one in learning all this stuff, frankly it's a painful process, one > I'm still in the midst of figuring out myself as I bring Squeak and Seaside > into the office. > > I've felt enough pain mapping objects into relational database that I've > also come to believe object databases are the way to go when dealing with > object oriented applications. Maybe things are more advanced in a more > enterprise Smalltalk like VisualWorks or Gemstone, I hope so, because the > state of the object databases in squeak at the moment seems quite alpha, and > still a bit too painful to be able to easily replace a relational database > for most apps. The Q2 issue tracker (which will be renamed to something cool when published, which will happen during august) is built using Seaside and Magma. During that work we have written some generic components for Seaside (like a nice but simple object driven TOC and a CSS based (no frames) "left side toc, right side scrollable content"-layout) and adapted a connection pool class from Kilauea for Magma so that Seaside sessions quickly can pick up established Magma sessions (with cached persistent objects). Our experience so far is that Magma currently works very good. We have had no corruption and I have only discovered two bugs so far, one only affected performance and the other only appears during heavy debugging etc and I am not even sure it is Magma's fault. We are now beginning to work with the index and multi-index query capabilities that is recently being added - and it looks very nice. I have worked with GemStone quite a lot (both St and J) and I think Magma gives almost the same, but with a much simpler architecture. The fact that it is all Smalltalk with source is also a bonus. There is one scalability issue that we are mulling a bit and that is the fact that the sessions are not sharing persistent objects at all. But with some appropriate stubbing I think that can be avoided as a problem. Best would of course be if Magma somehow magically could share objects between sessions, as long as they are unmodified - but as you can imagine that is a hard problem. Anyway, this app will be published soon and I think it can be used as a nice "real world example" or perhaps even be stripped down and complemented with a tutorial it could form some kind of WebAppInAMinute-bootstrap. regards, Göran _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> Our experience so far is that Magma currently works very good. We have
> had no corruption and I have only discovered two bugs so far, one only > affected performance and the other only appears during heavy debugging > etc and I am not even sure it is Magma's fault. We are now beginning to > work with the index and multi-index query capabilities that is recently > being added - and it looks very nice. > > I have worked with GemStone quite a lot (both St and J) and I think > Magma gives almost the same, but with a much simpler architecture. The > fact that it is all Smalltalk with source is also a bonus. > > There is one scalability issue that we are mulling a bit and that is the > fact that the sessions are not sharing persistent objects at all. But > with some appropriate stubbing I think that can be avoided as a problem. > Best would of course be if Magma somehow magically could share objects > between sessions, as long as they are unmodified - but as you can > imagine that is a hard problem. > > Anyway, this app will be published soon and I think it can be used as a > nice "real world example" or perhaps even be stripped down and > complemented with a tutorial it could form some kind of > WebAppInAMinute-bootstrap. > > regards, Göran Besides the app itself, which is great btw, I'd love to see a more detailed write up of your experiences building it, and more generally, ODB's and the mindset one needs to use to work with them. What made you decide to use a session pool rather than have a magma session per Seaside session? Is any of the stuff you've built to marry Magma to Seaside general enough that it could be used with Goods and Seaside? Could there be a small Seaside persistence framework there, that could allow the ODB to be pluggable? _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by stephane ducasse
Magritte (and Pier) may be appropriate for that kind of app. Why not
working on a magritte->RDB ? stephane ducasse wrote: > I should just tell you the context of this idea: > It seems to me that there is market that we miss: simple web > application development. > Seaside is cool for complex flow ones. But why can we have something > really simple to > define a domain (ie my comix collection) and that we can edit, sort, > ... + store in > a stupid DB. > > Stef > > On 28 juil. 06, at 09:54, stephane ducasse wrote: > >>>> I was wondering if it would not make a lot of sense to have a small >>>> framework called STOR that mimic (especially the persistency part of >>>> RoR) in seaside and magritte. >>>> It seems to me that lot of people are doing simple application and >>>> that the persistance is really important there. >>>> What do you think about that? >> _______________________________________________ >> Seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by stephane ducasse
Stef,
I am on my way to the airport & will be traveling for three weeks. I will get back to you on this when I get back. On Jul 29, 2006, at 3:38 AM, stephane ducasse wrote: > Hi roger > > I would really to know your experience with seaside for the same > kind of problem. > And also I would love to know what should be done to get a "django" > for Squeak. > > Stef > > On 28 juil. 06, at 21:36, Roger Whitney wrote: > >> Others have given very good reasons not to do this: existing OR >> mapping layers, object-databases, problems with mapping complex >> objects structures to relational databases, problems with >> continuations holding objects, etc. I am not arguing against these. >> >> But while I have been doing some web development I have not used >> Seaside for a long time :(. I have been using Django. It has a >> simple OR layer, with all the problems others have mentioned. I >> have to deal with Python, which I am not very fond of, crummy >> environments, poor IDEs, no interactive debugging, etc. All the >> while wishing I was using Seaside. But I use Django because once I >> define my "object models" (really just simple OR mappings - talk >> about a mixed up object model) Django generates the database >> tables and an administration site to enter data and manage users, >> which saves time. For simple projects I am more than 1/2 done at >> this point. Most of the stuff I have been doing is simple enough >> that the problems people mention are not an issue. >> >> Of course except for one project that looks like it may push the >> boundary on what is easy to do in Django. So do I rewrite the app >> in Seaside? Well at this point I have already invested time in the >> Django, is it worth switching? These frameworks take some effort >> to master. Just look at all the questions on this list about how >> to do X in Seaside. The details of Django are fresh in my head, >> details of using Seaside are not so fresh. It would take sometime >> to become proficient again partially offsetting Seaside's >> advantages. So as a result Seaside looses mind share. I think what >> Stephane is saying we should try to make it easy for people to do >> simple things in Seaside so we can gain some mind share. >> >> On Jul 28, 2006, at 12:54 AM, stephane ducasse wrote: >> >>>>> I was wondering if it would not make a lot of sense to have a >>>>> small framework called STOR that mimic (especially the >>>>> persistency part of RoR) in seaside and magritte. >>>>> It seems to me that lot of people are doing simple application >>>>> and that the persistance is really important there. >>>>> What do you think about that? >>> _______________________________________________ >>> Seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >> >> >> ---- >> Roger Whitney Department of Computer Science >> [hidden email] San Diego State University >> http://www.eli.sdsu.edu/ San Diego, CA 92182-7720 >> (619) 583-1978 >> (619) 594-3535 (office) >> (619) 594-6746 (fax) >> >> _______________________________________________ >> Seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > ---- Roger Whitney Department of Computer Science [hidden email] San Diego State University http://www.eli.sdsu.edu/ San Diego, CA 92182-7720 (619) 583-1978 (619) 594-3535 (office) (619) 594-6746 (fax) _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by stephane ducasse
On Jul 29, 2006, at 3:32 AM, stephane ducasse wrote: > But why can we have something really simple to > define a domain (ie my comix collection) and that we can edit, > sort, ... + store in > a stupid DB. Hm, good point. In fact, why restrict this to programmers? Surely there's a market for a web-based tool like that aimed at typical business users... Avi Bryant Co-Founder and Co-CEO, DabbleDB http://dabbledb.com ;) _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Ramon Leon-4
Hi!
(back from vacation now) Ramon Leon <[hidden email]> wrote: > > Our experience so far is that Magma currently works very good. We have > > had no corruption and I have only discovered two bugs so far, one only > > affected performance and the other only appears during heavy debugging > > etc and I am not even sure it is Magma's fault. We are now beginning to > > work with the index and multi-index query capabilities that is recently > > being added - and it looks very nice. > > > > I have worked with GemStone quite a lot (both St and J) and I think > > Magma gives almost the same, but with a much simpler architecture. The > > fact that it is all Smalltalk with source is also a bonus. > > > > There is one scalability issue that we are mulling a bit and that is the > > fact that the sessions are not sharing persistent objects at all. But > > with some appropriate stubbing I think that can be avoided as a problem. > > Best would of course be if Magma somehow magically could share objects > > between sessions, as long as they are unmodified - but as you can > > imagine that is a hard problem. > > > > Anyway, this app will be published soon and I think it can be used as a > > nice "real world example" or perhaps even be stripped down and > > complemented with a tutorial it could form some kind of > > WebAppInAMinute-bootstrap. > > > > regards, Göran > > Besides the app itself, which is great btw, I'd love to see a more > detailed write up of your experiences building it, and more generally, > ODB's and the mindset one needs to use to work with them. Yeah, I intend to write quite a bit about it. > What made you decide to use a session pool rather than have a magma > session per Seaside session? Is any of the stuff you've built to marry Currently we have a compromise - we use one magma session per Seaside session, but it is allocated from a pool. This means we cut out the session creation time, but more importantly - the session is "hot" so we keep the cached objects of the session. But the problem with using one Magma session per Seaside session (which thus remains for us) is that if you have a large persistent domain model AND you wish to cache quite a bit of it - then you get: numberOfObjectsInRAM = numberOfSeasideSessions * objectsCachedPerSession So if you have 100 concurrent sessions and 10000 objects cached per session you get a million objects. Ouch. One approach I have been toying with in my head is to use a single readonly Magma session and let all Seaside sessions share it. That session could then be allowed to cache a large part of the domain model. Then - when you know that you are going to modify something - you allocate a new session from the pool (or create a new one) and perform the Magma transaction using that one instead. But there is one tricky problem - when do we update the shared Magma session and its cache of objects? Seaside/KomHttpServer is serving using multiple processes (which might be a problem in itself btw, but we could protect the session using a Monitor) so we do not have a natural point in time when we could refresh the session. One idea that surfaced before going on vacation was to use TWO readonly sessions and then have a global flag that we set whenever we make a Magma transaction modifying the db. All Seaside sessions then use readonly MagmaSession A, and when a modification is made we issue an abort to MagmaSession B (which noone uses) and the ongoing Seaside sessions can continue to run using A. When B is refreshed we migrate all Seaside sessions over to B. The above approach means that we get a possible delay before the modifications are visible to the users, but it should be small. I still need to bounce the above idea on Chris Muller (Magma author) and see what he thinks. And finally - yes, this is a bit of "premature optimization" but 100 concurrent users for this app is actually a reasonable number. > Magma to Seaside general enough that it could be used with Goods and > Seaside? The "integration" part is very small. Just a hook to abort the session at the beginning of the HTTP request. One optimization we have done is that we only abort if a global flag has been set showing that there actually has been a modification to the db since the last HTTP request. This would obviously not work in a multi image deployment scenario - but we got rid of the MagmaSession abort penalty for most of the requests (and I believe it gets aborted twice because Seaside typically does a redirect on each request). > Could there be a small Seaside persistence framework there, > that could allow the ODB to be pluggable? Well, I have implemented such "facades" on a few occasions before but typically you end up having to cheat in the end anyway. And we don't have that many ODBs to choose from. :) regards, Göran _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Avi Bryant
>> But why can we have something really simple to
>> define a domain (ie my comix collection) and that we can edit, >> sort, ... + store in >> a stupid DB. > > Hm, good point. In fact, why restrict this to programmers? Surely > there's a market for a web-based tool like that aimed at typical > business users... :) I thought you would think about that :) ;) Still I guess that my point is valid. Domain + magritte + seaside + xxxx => my dummy object on the web. > Avi Bryant > Co-Founder and Co-CEO, DabbleDB > http://dabbledb.com > > ;) _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |