Dynamoose: One table multi schema ?

[arifsetyawan]

i have case using multiple schema in one table. as follow example

var schemaCar = { id: Number, type: String, airbag: Number };
var schemaMotor = { id: Number, type: String };

var MotorModel = dynamoose.model('Vehicle', schemaMotor);
var CarModel = dynamoose.model('Vehicle', schemaCar);

CarModel.create({ id: 1, type: 'mvp', airbag: 2 }, callback);

In dynamodb the item recorded without airbag key and i think it is because the CarModel is initialized after MotorModel. When i remove MotorModel its normal on dynamodb.

is Dynamoose cannot accept multiple schema in one table?

[fishcharlie]

@arifLogic This isn't supported in Dynamoose currently. The only idea I have is to use the saveUnknown option in your schema.

The other thing, is in your current example just have your schemaCar and CarModel and go from there. The airbag property is optional as all properties are optional by default in Dynamoose unless specified otherwise.

Maybe you have a different use case and you were using a simpler example, but I wouldn't have 2 schemas in this case because they are so similar. airbag is optional so just go with that. If you have different schemas or a better example I would be happy to take a look, but that is how I would handle it personally.

[sjensenihi]

I just wanted to chime in and say that I'd like this feature too. AWS says that many web-apps can be served using a single dynamoDB and for hierarchical database organizations you can pretty efficiently organize dynamo using a type(hash) and id (scan) arrangement like this:

courses -> type (hash), id: id (scan), name, description, image
lectures -> type (hash), id: courseId#id (scan), name, description, image, level
question -> type (hash), id: courseId#lectureId#id (scan), text, image, type, videoLink
answer -> type (hash), id: courseId#lectureId#questionId (scan), text, image, x, y, etc

Having a single table means that you can create a single GSI to query across say name and type, instead of needing to make a GSI for every table type.

[fishcharlie]

I just realized I misunderstood what was being asked. This is a duplicate of #301 and #337. I need help building it if anyone would like to help.

I think of a model as a DynamoDB table. But we are trying to add support for nested schemas, not nested models tho.

I still think @arifLogic's example won't quite work with the system being proposed. But @sjensenihi your system might be possible with the proposed system.

Would love help building it if anyone would like to help. Aiming to get it into Dynamoose version 0.9. But not sure if it will happen.

[fishcharlie]

Closing as duplicate of #301

[bush]

The problem with saveUnknown is it will break validation. I can't pass a user provided object from - say - an incoming request into the model. Now you have would have to check all the incoming parameters then pass them into the model which makes the schema redundant in some ways. The problem with the current interface design is that it is following the one class per table and assuming that users will want a fully normalized table design. This is a great video by the PT of DynamoDB: https://www.youtube.com/watch?v=HaEPXoXVf2k . He describes a one table per application pattern with a denormalized design. Many apps or micro-services can construct one table in such a way that they have many access patterns. I'm trying to think of how the interface could be changed to better support the patterns describe the the DynamoDB PT. @fishcharlie I'm happy to chat about this if you like ...

[manh-vv]

I don't understand why this is duplicated of #301. I would request for reopen this issue.

I am recently faced with this problem, and finding solution too. Let's take example from https://github.com/dynamoosejs/dynamoose/issues/295#issuecomment-384363402

My workaround solution is creating big schema which contains all properties from all models.

[rudieros]

Could we reopen this? Single Table designs work terrible with the current API since we would have to give up on benefits like validation.

Maybe the solution would be optionally detaching the model's name from the table's name by configuring { tableName: 'MyTable' } in the schema options, although I have little idea as to how much it would mess the validation mechanics. I understand that with a solution like this a user is prone to accidentally mixing documents from different schemas in the same query if the modelling/querying was not done correctly.

[fishcharlie]

@manh-vv @rudieros Feel free to submit a PR if you'd like and I'd be happy to review it. It is similar enough to #301 that I closed it.

For most of my purposes, this project does the job I need it to very nicely. As I find more things I need in the project, I add them, or bugs that need to be fixed.

So, although I consider this project to be maintained and active, I'm not able to dedicate the time to launch a massive effort to get this done at the present time.

That could change tomorrow, next week, next month, and I'll have time to launch an effort into investigating this and implementing it. But until then, PRs are always welcome! 😃