-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for embedded objects #565
base: develop
Are you sure you want to change the base?
Conversation
Hello @vitusortner and @mqus , I re-made this feature using a better approach for declaring embedded classes. There are still some problems like creating the column name, but I would like to request a first review for validating this approach. |
@vitusortner Updated PR description explaining how to use this feature. |
} | ||
return parameterValue; // also covers positional parameter | ||
} else if (field is Embed) { | ||
// return _getConstructor(field.classElement, [...field.fields, ...field.children]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
delete
); | ||
|
||
/// The database column definition. | ||
String getDatabaseDefinition(final bool autoGenerate) { | ||
if (embedConverter != null) { | ||
throw InvalidGenerationSourceError( | ||
'You ', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
switch message error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for taking the time to implement this!
I really like that you take the road of the type converters, this seems to fit in well, as type converters basically do the same thing (modulo converting one to many attributes and being able to set converters more precise). But for the API surface I rather like rooms approach more (see the comments). This is just a rough review though and @vitusortner surely also has some opinions :D
I enabled the CI pipeline, just ask if you want to know something :)
I'm curious to hear your opinions.
import 'package:floor/floor.dart'; | ||
import 'package:sqflite/sqflite.dart' as sqflite; | ||
|
||
part 'database.g.dart'; | ||
|
||
@Database(version: 1, entities: [Task]) | ||
@TypeConverters([DateTimeConverter]) | ||
@Database(version: 1, entities: [Task], embeds: [Timestamp]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to include the embeds here? doesn't it suffice to annotate the usage in the entities/views?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to include if we annotate the embedded class, if we annotate the variable like room then we don't need to include here.
@@ -7,7 +8,10 @@ class Task { | |||
|
|||
final String message; | |||
|
|||
Task(this.id, this.message); | |||
// @ColumnInfo(name: '') | |||
final Timestamp timestamp; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm personally in favor of having @embedded
here, like in room to be able to more finely adjust where to embed and where to type convert... what are your opinions here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello sir!
I don't have a background in Android/Java so I was not aware of the room approach.
I think that annotating the class as an embedded type is easier as we need to annotate it just once, instead of annotating every time we declare it inside an entity class. For finely adjusting, as we have just the prefix
string, I thought we could use the ColumnInfo name
as we already do for other variables.
If you prefer the room approach I can modify it, just tell me :)
Hello, any news here? |
Very nice feature, thank you @marcosmko for the job ! I have one suggestion : For exemple :
Thanks you ! |
Hello @Johann673 , actually I'm still waiting for the project owner to review this PR so I could make improvements... 😅 |
Looks great but why still don't reviewed? 🤔 |
What is missing? |
@marcosmko An embed class can't be an Entity also? |
Why is it not merged? I just need this feature |
Waiting for code review, guys :/ |
a lot of time has passed. Didn't the owner have time to review? |
What's progress for this feature? |
Currently it postponed for a while. The MR is so far from the actual develop, so it needs to review again and update. |
Any update ? |
Implementation for
@Embed
annotation based on #328 by @hsul4n.In this approach, you declare an
Embed
class exactly like you declare anEntity
, with support forColumnInfo
annotation too.When declaring your
FloorDatabase
, you pass to@Database
annotation the classes that are for embedding in other entities (I also added TypeConverter for DateTime).And finally, you add the
Embed
type to yourEntity
.Note that I added the possibility for naming the embed type. If you do not declare a name, it will use the field name as a prefix. If you declare an empty name, then it will embed the Timestamp fields directly.
For example, in the provided example it will generate
timestamp_created_at
andtimestamp_updated_at
columns, while if you provide an empty name it will generatecreated_at
andupdated_at
columns.Closing #9