<[EMAIL PROTECTED]> writes: > Well, I've come across a few. A handful of hanging bugs that I've managed > to work around - the latest one to do with dropping/creating tables, > different to another one mentioned on here. It's default caching strategy - > I recently wrote a performance test to see how my models worked with > millions of records, argh - default was they're all stored in memory. It > only supports a subset of table management features (correct me if I'm wrong > but no way to drop an index etc). Performance madness - that it > automatically accesses the database when you set/get fields in the model > objects - letting users do users.save() is hardly a mind-strech.
I've also noted those performance problems, but I've solved them by working with subsets of data (nobody is going to look at millions of rows so I am retrieving sets of 100, for example. About accessing the database on set, I'm using lazyUpdate, as in the docs, and it just access the database when I .sync(), so this is a non-issue to me. With regards to get, if you're using cache and the information is cached it might not go there again. Unfortunately, caching and multi-threaded applications doesn't work fine so... Anyway, how did you want it to retrieve the latest information considering that there are several parallel concurrent users that might be working on the same record you're retrieving? If they changed it, then you have to fetch it again. Either that or work with wrong information. With regards to table management, I'm not creating / dropping indices in a normal situation, so I don't mind having other routines to do that (even using SQLObject's sqlbuilder if I need to run queries by hand). This is an exception in daily use so I handle it as an exception as well. > On the other hand code written with it has a simplicity which I really like > - more so than the other ORM's I've looked at. I got the same conclusions... > In short, it's useful enough (with tweaking) but not quite finished. And > before it got finished Ian decided to rewrite it. Yep. He saw that without this redesign things would be harder than they needed to be, so... > Yes, I could switch to SQLAlchemy but I'd rather be using TG out of the box > especially since there are tool dependencies on SQLObject now. You can code using only SQLAlchemy in your code. You can't use all toolbox tools, but it won't prevent you from getting what you need done. > Never mind, guess I'll manage and sit tight for SQLObject2 If it gets ready before SQLAlchemy gets stable, then it might be a good choice. Otherwise you can use some compatibility layers that already exist within TG and run SQLAlchemy. Of course, not everything works with it when you consider the toolbox, but for your system it might be worth the change (and even let toolbox specific parts be handled by SQLObject). -- Jorge Godoy <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
