Multiple models and views in 'transactions'

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,

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

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,

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

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.

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

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?

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,