On Smalltalk

I was wondering if you could elaborate more on the following line:

"Most of the schemas I have to work with suck, and can't be changed because people used the database as an integration point for multiple apps (God I'm tired of seeing people make this mistake)."

I've seen applications that use related data, but on completely different database products. One uses Oracle and the other SQL Server. It's a nightmare to keep the databases in synch. I've seen it tried at the database level and the web services level and neither worked out real well. In this case the politics maybe the biggest problem, but not having the data in one place for both applications doesn't help either.

> Most of the schemas I have to work with suck, and can't be > changed because people used the database as an integration > point for multiple apps (God I'm tired of seeing people make > this mistake).

I've spent the last couple of months developing a generic state machine to prevent the need to do this - and that circumstance was one of my motivating factors. I'd be interested in your thoughts about my system - perhaps we could talk over Skype or something at some stage?

Email is:Firstname @ parentdomain

Anon, having spent a few years working with databases where the database was treated as an integration point between several applications, I've come to the belief that this is a bad practice and becomes a big ball of mud making any new application development extremely hard. It's too much a data centric point of view... and people don't use data, they use applications.

The database should exist to serve the application, not vice versa. The data itself may outlive the application, but it must still be subservient to the application for which it serves. Treating the database as an integration point means using it as a big giant global variable... and we know how bad those are.

At this point in my career, I feel applications should exist independently, and be free to evolve independently, with a private database that only it can use. Should two applications need to integrate, then "they" integrate via services, they don't reach into each others databases, violate encapsulation, and grab what they need.

I find integration via services vastly easier than integration via one giant global variable database that is so fragile that touching it might break 5 other applications.

@Ramon... I couldn't agree with you more. I'm playing in the mud at the moment and it aint fun.

And I totally agree with integrating applications via services. I've just started a new job where a number of applications are dependent on the same database and I'm experiencing the pain of fragility quite frequently.

"Seaside is far more advanced than Ruby on Rails, and is a much better web framework for doing anything complex, but we're still missing the market on CRUD apps."

I was wondering if this was the case. In all the documentation about Seaside I've read I haven't seen one talk about ORM or a framework for it, which indicates to me that developers who want this have to fashion it themselves. I have seen a few rare messages from Seaside developers in the discussion groups who say they are trying to create easy O-R mapping, like what exists in RoR. That would be a good start.

Yea, the problem is that in the Smalltalk community, relational databases just aren't all the rage, this is the one community that really does prefer object databases. Gemstone is releasing a version that works with Seaside soon, Magma is being used as well.

Squeak is the problem really, not Smalltalk. I'm sure it'd be much easier to find a real O/R mapping solution in Visual Works, that works on a wide variety of databases. Glorp does work on Squeak, but only with Postgres.

As far as mapping frameworks goes, Rails is extremely simplistic, and can only do a fraction of what something like Glorp can do, but... turns out that it does 99% of what people want, for simple web apps that "own" their own databases. Rails hits the sweet spot by auto-mapping to a schema based on sensible defaults (mostly, I despise it's pluralizing of table names).

Hopefully, Alan will get Glorp doing something similar soon, and maybe someone will step up and write some decent db drivers for Squeak (I hope) and we'll be able to compete in that Rails CRUD arena, but for now, we can't match rails simplicity for simple CRUD against a "relational" database. Now an object database... that's another story entirely.

I just want to make some simple statements.

1) You can turn off table pluralizations in Ruby on Rails

2) You can add a few calls in your models to let Active Record know your legacy db schema. Then you have the full glory of the OO models and finding and saving, etc.

3) This is the first I've heard of Seaside. I'm glancing at it now. Does it provide built in schema migrations? how about built in unit and functional testing? routing and pretty urls? page and fragment caching? MVC and built on good, intuitive design?

There isn't a web framework that will meet everyone's needs, but Rails supports quick, structured web development with excellent access to a db without writing crazy sql. With baked in testing, ajax, etc. it is a great option worth considering for use.

Don't misunderstand, I'm a fan of Rails, for what it does, it rules the roost. Seaside targets an entirely different market, and isn't a full stack solution like Rails. Seaside is for complex web Applications with lot's of workflow.

Seaside does nothing with relational databases, that's up to you, it's just a UI framework. Seaside makes programming web apps exactly like programming desktop apps, and completely hides all the related ugliness of the web.

Rails is a slick implementation of todays web programming methods and techniques, Seaside is something else, it's tomorrows methods. If you want a total solution, use Rails, if you want to do stuff that difficult to impossible to do with current techniques, try Seaside, it'll likely be fairly easy.

Seaside has fantastic Ajax integration, using the same libs as Ruby I believe, Prototype and Scriptaculous. Databases, relational ones anyway, are a weak point with Squeak, so it's not ready to take on Rails as a total solution for CRUD apps, yet.

Seaside doesn't even look at URLs, you can make em up however you see fit, and parse them however you like. There are no pages to link to, it's totally different than traditional web programming techniques.

Rails relies heavily on code generation, Seaside's not about that. You have to write your own test... and honestly, I'm not sure any test that can be generated... is worth doing. I use unit tests as a design technique, not as an afterthought. Any framework that can generate working unit tests, can just generate working code, the tests aren't necessary.

ActiveRecord only maps single table inheritance, afaik, so it's not adept at handling legacy schemas where you might need to map 6 tables to get one solid object, nor does it try. Rails isn't about Enterprise apps, it's about simplicity. Glorp is much more powerful as far as mapping objects to databases goes, it's just more difficult to setup and configure, but that's being worked on.

Migrations rock, activerecord rocks. If a stack is missing them then it's not worth using.

BTW if you need to join six tables to get at a model something is wrong. If you can't do that with a view you are using the wrong database.

That's naive, only Rails has Active Record, and it's only a simple O/R mapping layer. The only thing special is its zero config, which means squat once the app is developed. Even Hibernate on .Net or Java, is more feature complete than Rails, as far as mapping to difficult schema's goes. Rails is nice, but it's far from the only solution worth using.

BTW, there's a reason they're called "legacy" databases. When databases support FULLY updateable views, you might have a point, until then views aren't much help when you're trying to write your objects back to a database.

You got me curious with Glorp and its higher flexibility/power wrt to AR. Do you happen to know how it compares with SQLAlchemy ? Seems to be regarded as the most complete ORM in the python world these days, although it's kinda harder for simple things compared to SQLObject (which is closer to AR).

Honestly, I couldn't tell you, but from looking it up, I'd image Glorp is much like SQLAlchemy, a complete ORM solution capable of quite complex mappings, but maybe a little much when wanting to do a simple active record thing, though Alan's working on that as well.

I note that one of your complaints is that Glorp in Squeak only works with Postgresql. That's just a limitation of the Squeak port. Glorp is extremely portable between databases, and aware of a good few. I mostly use Oracle and Postgresql, and force myself to tests against SQL Server every now and then. As long as there's a way of accessing that particular database within Squeak, it should be a very small amount of work to hook Glorp up to that driver.

Oh I'm aware of that, but there isn't a Sql Server driver for Squeak, and using ODBC uses the FFI which blocks the VM.

I'm not at all blaming Glorp. Glorp fucking rocks, and I don't mind using PostgreSQL at all, it's just that if Squeak had a Sql Server driver.... I could use Glorp against my legacy databases at work instead of having to use web services. I'm stuck with a lot of Sql Server databases that can't be changed. Maybe someday I'll try writing a driver, but it's not something I've ever done, so I don't have a clue what's involved.

For new/side projects, I'm using Postgres and Glorp.

I guess you're right about the tables. However my update tool does not work and i can't get it working :/