Multiple models and views in 'transactions'

rubyonrails-talk
1

Hi,

I'm not surely if I'm going to be able to explain well ...

We have a Rails 3.2 with backend PostgreSQL.

We have 5 models that are nested/related between them, and all must be created/updated/destroyed in block, like a transaction.

Those models are created using very complex views and some modals, this is for a very complex ERP.

We don't want to store 'invalid data' in the real tables, like using some attribute like 'pending' or 'modifying'.

One solution that I'm experiment with it, and it seems it can serve us, is using schemas of PostgreSQL. I have defined in a new schema the same tables that we need for this purpose.

In Rails, I duplicate de Model (it's not DRY anymore...) with almost same attributes but using the schema.table notation for the model.

When I create a new block set, simply I use the 'new_model_schema' variatons, and finally, when I want to save, simply Insert all the rows from this schema to the real schema (public in our case), all wrapped in a block transaction.

But if we have to modify, we have to move all possible data to the new schema, make there all the changes, and if it's validated, update the values in the public schema.

This is not DRY, we have to have duplicated tables in two schemas, and we have to duplicate models in Rails, and of course, controllers, and views.

This approach maybe works but at the end will be a pain to maintain ...

What alternatives we have ?

A Javascript MVC framework like backbone.js will help us ?

In this case we have to duplicate some code also with model/views in backbone, but at the end, the Rails controllers/views stay the same.

How are you solving this kind of complexity ?

Thanks for your time and help!

regards,

2

Is there too much data to hold it all in the session till it is ready to go?

Whatever route is there a problem with the possibility of one of the tables getting updated by another user whilst this user is collecting the data, then if his data is put in the database (whether inside a transaction or not) the data collected in the session or your schema table would remove the changes already made.

Colin

3

Colin Law wrote in post #1085205:

is for a very complex ERP.

We don't want to store 'invalid data' in the real tables, like using some attribute like 'pending' or 'modifying'.

One solution that I'm experiment with it, and it seems it can serve us, is using schemas of PostgreSQL. I have defined in a new schema the same tables that we need for this purpose.

Is there too much data to hold it all in the session till it is ready to go?

it depends ...

1 main model with more or less 4 nested models and each of this 4 models 5 more ...

Whatever route is there a problem with the possibility of one of the tables getting updated by another user whilst this user is collecting the data, then if his data is put in the database (whether inside a transaction or not) the data collected in the session or your schema table would remove the changes already made.

This can only happen when modifying, not when creating.

And I think I can control more or less with database-semaphores in some way attached to sessions.

The main problem here is code duplication, if I store the data into session, I have to decollect and update in some way the session data and the views, so some views will be updated from data from session or from database ...

thanks,

4

I wonder… Is there a possibility that if your database has multiple tables that are related with foreign keys,

whilst a user is filling in fields of forms, etc - is it possible for another web user to overwrite records or to create

records with the same id that would later get overwritten by the ‘slow’ user.

In general, is there a potential database consistancy problem with multiple Rails web users. If so, what is the

solution. I have never seen this discussed in any Rails book I’ve read.

-joe

5

There's a potential consistency problem with *any* web application, not so much on create (the DB should make sure created record ids are unique) but with updating/deleting.

How you deal with that depends on your application. You might only allow people to edit records they created. Or you might add a "lock" to the controller's edit method to serialize access to a record.

It just depends on your requirements.

6

Thanks for your replays, but the main point I'm asking here is how I can isolate all this new/update nested records using multiple modals and views:

1. using schemas and duplicate models,controllers,views 2. using a Javascript Framework like Backbones and do this stuff on the client side 3. ?

thanks again,

regards

7

Thanks for your replays, but the main point I'm asking here is how I can isolate all this new/update nested records using multiple modals and views:

I guess I don't understand the problem. Originally you said:

We have 5 models that are nested/related between them, and all must be created/updated/destroyed in block, like a transaction.

So why don't you just use transactions when you interact with them?

8

Hassan Schroeder wrote in post #1085530:

Thanks for your replays, but the main point I'm asking here is how I can isolate all this new/update nested records using multiple modals and views:

I guess I don't understand the problem. Originally you said:

We have 5 models that are nested/related between them, and all must be created/updated/destroyed in block, like a transaction.

So why don't you just use transactions when you interact with them?

Because when I create the first model, I have to show other views, all with Ajax, where the user can create more nested models, those models are created using modal views, and once they are added, they are rendered in some tables.

I can't use transactions between connections ...

Hope now is more clear :slight_smile:

thanks,