Re: [web2py] Re: Proposals for New Tagline
Hi, I've read all the discussion about the tagline... and unfortunately I cannot agree with most of the votes. But maybe it's because I am coming from enterprise world and I have a different perspective... For me if you put enterprise in the tagline that means only a few things; it's a mature, production-ready, stable and high quality, proven software. Thats because enterprise companies avoid investing in betas or experimental solutions - they do prefer a stable, proven software even if it's not so cheap. So if you want to attract developers like me - people with enterprise experience - leave this word in tagline. Otherwise they will choose Django only because it's more popular... Personally I would think about tagline that shows 3 points: enterprise quality and stability, agile development, fast learning Regards Adam
[web2py] Re: Proposals for New Tagline
> > Hi, > >That may be true -- for you. Web2py should target the market sector > >that it wants and try to appeal to that sector. > > And thats the question that I am not able to answer: what is the real target for Web2py ? I believe it deserves separate discussion. And I think it's much more important that the tagline itself. Anyway please don't underestimate the enterprise interest in Web2py. Even if it's not likely that it will be selected as main environment for some large scale business applications it still may be used for some side projects, internal tools or even as a part of some bigger solution. However when I talk about 'enterprise' I don't even think about the corporations itself, I am more interested in people. Poor developers that used to work in big companies but decided to start up a new one... thats my point: these people are very often a founders of new startups. These people are responsible for choosing technology. This is a real target. But thats only my point of view :) I am quite new here and I may have no idea whats the real future of Web2py, where the developers want to go in next year or two, what target are they interested in... Maybe indeed its only me with my mind indoctrinated by over 10 years in corporate world :) The bottom line is that if anyone would like to discuss how to attract new people to Web2py the tagline is IMHO the least important thing... documentation, features and web-content (blogs, tutorials, examples etc) is the path to go I think. Cheers Adam
Re: [web2py] Re: Proposals for New Tagline
> > web2py : A small framework that allow you to think Big ;-) > > Richard > > Web2py: solid as rock, easy as pie ;) I am not a native speaker so sorry if it sounds stupid ;) Regards Adam
[web2py] question from stackoverflow - DB transactions
Hi, Since I am still learning Web2py i used to search for knowledge here and there.. I found quite interesting question on stackoverflow that for my understanding is not answered yet.. The question: http://stackoverflow.com/questions/4979392/web2py-and-db-transactions As I understand the problem - and I am quite interested in answer - is: how to get a manual control over database transactions? In case there is a need to commit something manually before it's automatically committed by Web2py - it can be done easily. But what about the case when there is a need to have a more sophisticated logic and to put a couple of requests-responses into one DB transaction? I am not the author of the original question but I think that it's quite real business scenario.. for example the case mentioned in the question - when you want to give to user a few forms, every form is dependent on the form before and to avoid data misintegrity it's better to wait with commit until the last form is submitted... obviously everything can be put to the session(or cache or whatever) instead of DB but sometimes it's not a solution due to size of data. Any hints how it can be done? Thanks Adam
[web2py] Re: question from stackoverflow - DB transactions
Hi Kevin, Thanks for answer. I agree that for multipage wizards usually session should be OK. However I can give you two cases from my past projects that are not so easy (developed in java anyway). OK, its not just a wizard - but the problem is the same. a) There were an analytical application that had to display a table data (a few hundreds of rows, 8 columns). Application user had a number of fields that he could change its values - and after submitting - he could see changed database data. However the changes must not be committed until the results was approved by user - he could play with it number of times until the results were ok, than finally - submit it (commit data). In other words - it's kind of "live spreadsheet" based on database. b) There were a simple application for a very small factory that was assisting in scheduling of production. It was really simple however there were a thousands possible product components, one schedule had to contain a few products to be produced. It would be really painful and basically it would make no sense to solve it with session - it would be close to storing a database in session. Even if DB small it's still better that session for storage ;) Of course both cases could be done with different approach - that our job to find a solution even if its seems there is a dead end :) But the easiest one for me is just using database without commiting transaction (to make sure the data integrity is not broken). Using database for some intermediate storage is just a "design pattern" - it can be done in other ways but this is also a good solution. Please don't underestimate the issue: even in very simple scenario it can be useful: - lest say we have application with tasks and for every task user can add comments - user create task and then create comment - comment is on new page - before he submits comment he decides to CANCEL the whole operation.. I would just rollback data, but without such possibility you need to delete the task.. :) Sometimes leaving task without comment is not so nice - it was created by mistake for wrong project for example... Stupid example but very real use case for 'rollback'. Anyway - it's not a problem for any real current project - I just need to understand how Web2py works to not make any mistake when choosing it for some future project. But I really believe that even if Web2py does not support it - it should be quite easy to make such improvement. But its just intuition - maybe I cannot see some issue... The idea should work like it: - the db object in Web2py should has a property - lets name it "persistent connection". For compatibility it could be set by default to no - in such cases nothing changes. Howevere if you change it to yes you turn on following changes: - when the connection to DB is made the unique ID of the connection is stored in DB object (and in session) - next time when the connection is requested if the ID is not empty - the same connection is restored from the pool - every connection in the pool that should be 'persistent' should also be marked wiht for example session UID - to prevent assignment of it for other session - there should be some kind of very basic garbage collector (or maybe there is something like it???) that should 'free' all persistent connections older than some amount of time Probably I am missing something but it seems it's not so complicated :) To be honest - this kind of persistent connection could be even sometimes faster that the old one - but for the price of resources of course. If you or anyone could explain what I am missing in the idea above ... :) Maybe it's only me but I believe this feature could be very handy for applications dedicated to smaller number of concurrent users.. Or - maybe it does exists in Web2py already ? Thanks Adam
Re: [web2py] Re: question from stackoverflow - DB transactions
Just one thing to make it clear - maybe i shouldn't write mails so fast :) In the ideal word when you start designin your application from scratch - drow all thge diagrams or do it in any other way, traditional or agile - it doesn't matter - but when you start from scratch you can do everything you want. In this case I full agree with everything that has been said already -- keeping multiple-requests db transactions is bad practice. Period. I think everybody agrees here :) The real word for me however is different: I have to work for different systems working side by side. Sometimes for example I have to write stupid application that is not really more complicated that the famous facebook clone. The only difficulty is that it MUST work on existing data, use (partially) existing tables, stored procedures etc etc. In such cases if I would say to my boss or client : drop this billion dollar 20 years old system and buy new one with different data structure - it could be last of of this job :) I must find a solution that: a) works b) there is someone that is willing to pay for it. I believe thats the real reason why I am so liberal for this kind of approach like killing user db session just because its to long... but in one project it was the only solution that someone wanted to pay for. So - to summarize: I agree if talking about theory, I disagree if talking about real life - but it's not a general chat so I suggest to close this issue. If I will encounter it in real project I will raise it back, for now - it's not worth it. Thanks for all the answers, even if I disagree less or more ;) Regards Adam
