gmane.comp.python.sqlobject

the future of sqlobject

Oleg, I was searching for a document outlining the future of sqlobject
but couldn't find any so here it goes:

In the current development phase are you primarily concentrating on
bug fixes and maintenance releases?
Do you have plans for developing totally new features?
Would you be willing to develop new features if they are requested?
How long you think you will support sqlobject?

I would be grateful for any other thoughts you might have on the subject!

And thanks for the great work you have done for sqlobject users like myself.

Cheers,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

headers

Oleg Broytmann | 21 Apr 06:48

Re: the future of sqlobject

Hello! The first thing I want to tell is that SQLObject is a community
project. There are people who provide patches (sometime big patches for
major features), there are developers who have commit access to the
Subversion repository. I am one of those, but certainly far from being the
only one.

On Sun, Apr 20, 2008 at 09:24:43PM -0700, Daniel Fetchinson wrote:
> In the current development phase are you primarily concentrating on
> bug fixes and maintenance releases?
> Do you have plans for developing totally new features?

   I have a rather big TODO file with a lot of planned small new features.
>From private mail I new there are other features brewing, though if and
when they will be released nobody can tell.

> Would you be willing to develop new features if they are requested?

   Certainly. Unfortunately I don't have much time to spare, so I have to
carefully choose what and when to develop.
   The best way to add a feature is to implement it itself. A good patch
with tests will certainly be applied. Documentation is big plus.

> How long you think you will support sqlobject?

   Well, I must admit I am not the best possible community leader, neither
the most brilliant developer. So I'd very much like to hand SQLObject to
someone better suited for the task. Until that, though, I am obliged to
support it myself. After all, my company uses SQLObject in a number of
commercial programs.

(Continue reading)

headers

Daniel Fetchinson | 21 Apr 17:15

Re: the future of sqlobject

> Hello! The first thing I want to tell is that SQLObject is a community
> project. There are people who provide patches (sometime big patches for
> major features), there are developers who have commit access to the
> Subversion repository. I am one of those, but certainly far from being the
> only one.
>
> > In the current development phase are you primarily concentrating on
> > bug fixes and maintenance releases?
> > Do you have plans for developing totally new features?
>
> I have a rather big TODO file with a lot of planned small new features.
> From private mail I new there are other features brewing, though if and
> when they will be released nobody can tell.
>
> > Would you be willing to develop new features if they are requested?
>
>    Certainly. Unfortunately I don't have much time to spare, so I have to
> carefully choose what and when to develop.
>    The best way to add a feature is to implement it itself. A good patch
> with tests will certainly be applied. Documentation is big plus.
>
> > How long you think you will support sqlobject?
>
>    Well, I must admit I am not the best possible community leader, neither
> the most brilliant developer. So I'd very much like to hand SQLObject to
> someone better suited for the task. Until that, though, I am obliged to
> support it myself. After all, my company uses SQLObject in a number of
> commercial programs.

Thanks Oleg! I'm happy to hear that there are several developers and

(Continue reading)

headers

Oleg Broytmann | 21 Apr 17:30

Re: the future of sqlobject

On Mon, Apr 21, 2008 at 08:15:54AM -0700, Daniel Fetchinson wrote:
> maybe the work is too much
> for a single person.

   It is, to an extent. But anyone can help. Code, tests, documentation
- any help will be great help!

> Sometimes you hear people saying that sqlobject's
> development is slow

   Well, they have a point, alas.

> And the level of support you provide on this list is absolutely great
> and is a big plus in favor of sqlobject.

   Thank you!

Oleg.
--

-- 
     Oleg Broytmann            http://phd.pp.ru/            phd <at> phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

headers

Sam's Lists | 22 Apr 01:18

Re: the future of sqlobject

Oleg.. (and other developers)

I hope you don't mind the question....

But have you given any thought as to positioning against SQLAlechemy?

It's a totally appropriate answer to say that you'll just continue working on SQLObject and not really pay attention to what others are doing, of course.

But I think that if we want to continue to get new users, we need to have a reason to be chosen over SQLAlcehmy. Perhaps because we're easier to use or faster, or whatever.

I started using SQLObject because Turbogears recommended it. Unfortunately they now recommend SQLAlchemy. :(

It might be nice to dialogue with the Turobgears community and ask them what we could do to improve the product so that it would be the default choice again.

On Mon, Apr 21, 2008 at 12:30 PM, Oleg Broytmann <phd <at> phd.pp.ru> wrote:

On Mon, Apr 21, 2008 at 08:15:54AM -0700, Daniel Fetchinson wrote:
> maybe the work is too much
> for a single person.

It is, to an extent. But anyone can help. Code, tests, documentation
- any help will be great help!

> Sometimes you hear people saying that sqlobject's
> development is slow

Well, they have a point, alas.

> And the level of support you provide on this list is absolutely great
> and is a big plus in favor of sqlobject.

Thank you!

Oleg.
--
Oleg Broytmann http://phd.pp.ru/ phd <at> phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.

-------------------------------------------------------------------------

This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

headers

Daniel Fetchinson | 22 Apr 04:21

Re: the future of sqlobject

> But have you given any thought as to positioning against SQLAlechemy?
>
> It's a totally appropriate answer to say that you'll just continue working
> on SQLObject and not really pay attention to what others are doing, of
> course.
>
> But I think that if we want to continue to get new users, we need to have a
> reason to be chosen over SQLAlcehmy.  Perhaps because we're easier to use or
> faster, or whatever.

Sqlobject is easier to use and is more lightweight than sqlalchemy.
Correspondingly the learning curve is much less steep so for small
projects many would find it more appropriate. It's like bash vs.
python. For simple things python is an overkill, for more complex
things bash is not powerful enough and one should go with python.

> I started using SQLObject because Turbogears recommended it.  Unfortunately
> they now recommend SQLAlchemy.  :(

I also use turbogears with sqlobject. Both the current (1.x) and the
next (2.x) version of tg supports sqlobject. For 2.x the default will
indeed be sqlalchemy but that should not stop us from using sqlobject
since that will continue to be supported.

> It might be nice to dialogue with the Turobgears community and ask them what
> we could do to improve the product so that it would be the default choice
> again.

I don't think that will ever happen. Then again it should not matter
what the default is, the only relevant thing is whether sqlobject is
supported or not by the framework and it seems the tg developers
intend to support it in future versions (at least 2.x).

Cheers,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

headers

Nick Murdoch | 22 Apr 10:26

Re: the future of sqlobject

On Tue, 22 Apr 2008 03:21:26 +0100, Daniel Fetchinson  
<fetchinson <at> googlemail.com> wrote:

>> But have you given any thought as to positioning against SQLAlechemy?
>>
>> It's a totally appropriate answer to say that you'll just continue  
>> working
>> on SQLObject and not really pay attention to what others are doing, of
>> course.
>>
>> But I think that if we want to continue to get new users, we need to  
>> have a
>> reason to be chosen over SQLAlcehmy.  Perhaps because we're easier to  
>> use or
>> faster, or whatever.
>
> Sqlobject is easier to use and is more lightweight than sqlalchemy.
> Correspondingly the learning curve is much less steep so for small
> projects many would find it more appropriate. It's like bash vs.
> python. For simple things python is an overkill, for more complex
> things bash is not powerful enough and one should go with python.

Aye, that's true. I think SQLAlchemy has a better query construction  
language (although to be fair I haven't used SQLObject's all that much),  
but I much prefer SQLObject's ORM. Alchemy has the advantage of (as I  
found out recently) non-integer, multicolumn primary keys, a feature that  
I took advantage of in a previous project. However, the complexity of  
configuring it puts me off using it in favour of SQLObject nine times out  
of ten.

The difference to me is that SQLAlchemy requires you to know how SQL works  
in much greater depth, /and/ to learn how SQLAlchemy interfaces with it  
all, before you can start using it. I'm not a DB expert, and I like how  
SQLObject doesn't bother me with a lot of the details before getting on  
with it.

Nick

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

headers

Robert Forkel | 22 Apr 10:47

Re: the future of sqlobject

On Tue, Apr 22, 2008 at 10:26 AM, Nick Murdoch <nmurdoch <at> locayta.com> wrote:

>  The difference to me is that SQLAlchemy requires you to know how SQL works
>  in much greater depth, /and/ to learn how SQLAlchemy interfaces with it
>  all, before you can start using it. I'm not a DB expert, and I like how
>  SQLObject doesn't bother me with a lot of the details before getting on
>  with it.

i think this also holds the other way round. if you already know how
sql works, you might be better off with sqlalchemy. in my case, i
already had a legacy db with composite, non-integer foreign keys, and
changing the schema to make it work with sqlobject didn't really
appeal to me.

robert

>
>
>  Nick
>
>
>
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  _______________________________________________
>  sqlobject-discuss mailing list
>  sqlobject-discuss <at> lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

headers

Nick Murdoch | 22 Apr 10:53

Re: the future of sqlobject

On Tue, 22 Apr 2008 09:47:54 +0100, Robert Forkel  
<xrotwang <at> googlemail.com> wrote:

> On Tue, Apr 22, 2008 at 10:26 AM, Nick Murdoch <nmurdoch <at> locayta.com>  
> wrote:
>
>>  The difference to me is that SQLAlchemy requires you to know how SQL  
>> works
>>  in much greater depth, /and/ to learn how SQLAlchemy interfaces with it
>>  all, before you can start using it. I'm not a DB expert, and I like how
>>  SQLObject doesn't bother me with a lot of the details before getting on
>>  with it.
>
> i think this also holds the other way round. if you already know how
> sql works, you might be better off with sqlalchemy. in my case, i
> already had a legacy db with composite, non-integer foreign keys, and
> changing the schema to make it work with sqlobject didn't really
> appeal to me.

Oh, definately. One of my colleagues prefers SA for exactly that reason.  
Being able to fine-tune to that level certainly appeals to people, and as  
you say, if you have an existing schema, there's not much you can do about  
that.

I'd certainly be interested in working on SO, if I had any free time at  
the moment. I think having a roadmap or a ticketing system might be useful  
for people though, since it'd mean people would be able to browse through  
what needs/wants to be done next, and pick a favourite, rather than having  
to come up with an idea for a feature themselves.

Nick

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

headers

Oleg Broytmann | 22 Apr 05:24

Re: the future of sqlobject

On Mon, Apr 21, 2008 at 08:18:42PM -0300, Sam's Lists wrote:
> But have you given any thought as to positioning against SQLAlechemy?

   I haven't. There is a number of ORMs in the Python world (SO, SA, Storm,
PyDO, Database Row, Yet Another ORM, etc.) but I don't have any idea of
their advantages and disadvantages.
   The situation is similar to python web framework proliferation. Can
anybody explain the advantage of Zope over Django? Pylons over TG? web.py
over Quixote? Still people choose somehow...
   BTW, there are many people who despise the very idea of an ORM and use
DB API directly. ;)

> It might be nice to dialogue with the Turobgears community and ask them what
> we could do to improve the product so that it would be the default choice
> again.

   There are many people in this mailing list that use both TG and SO. If
some of them want to help communicating - you are welcome! Let's talk!
   And in any case - SQLObject needs more features, better quality, better
documentation. Whoever adds a feature, a line of code, a test or a line of
doc does a good job for SO.

Oleg.
--

-- 
     Oleg Broytmann            http://phd.pp.ru/            phd <at> phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone