> I'm still learning about it, but AFAIK this is the correct behavior for > SQLAlchemy. By calling flush() you are telling SQLAlchemy to save > whatever changes you have made within the context of the call. Calls to > mapper.flush() will save all changes that the mapper governs, calls to > object.flush() will save all changes to that object, calls to > session.flush() will save all changes.
But, if you use transactions, the flushed data should rollback, as SQLAlchemy docs say. So, in turbogears, as transaction is automatic, I think it should ideally rollback. > Why are you flushing the Company object to begin with? Is there > something that is not working correctly when you don't do this? Consider this requirement - a company has many employees, and one among them is the CEO. The database structure would be Company(company_id, ceo_employee_id) Employee(employee_id, company_id (is the foreign key to Company)) Steps needed to create a new company with an employee: ceo = Employee(...) company = Company(...) comany.employees.append(ceo) # Flush so that you get ceo.employee_id generated session.flush() company.ceo_employee_id = ceo.employee_id In this type of case flush is necessary in the middle. I tried to avoid using circular foreign keys etc. but some problem came. In summary, as I see, in certain cases you can't avoid flushing in the middle. What I need is a suitable pattern to handle these cases so that the entire operation is either committed or rolled back. If a concrete example can explain things clearer, can I create a sample application and attach to a new ticket? thanks sanjay --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
