Appmaker saying
App Maker will soon deprecate the foreign key field. We recommend you
use relations instead.
What does it mean? Does it mean they are going to remove FK from Database tables or are they going to hide FK so developer/user cannot directly use it in app to enforce to use Relation.
Related
I have an existing view in my SQL database "view_account" which represents a account entity. This view is read only and has no primary_key field. Actually it has a primary key "id" but the field is not declared as primary key. I can also not change the table design, because its an automatic export from another application generating this tables (the automatic export is every week).
But thats not the problem cause doctrine don't care about "primary key" flag in the database until you don't update the schema.
But whenever i try to "doctrine:schema:update --force" doctrine wants to create this table. How can i ignore this view (or better the entity) from updating by doctrine? Marking the entity read_only with doctrine annotation is not working. Extending a own update-command will also not work, as i found out, it will not work since doctrine 2.4.7 to extend the doctrine-schema-update command (the update command method is ignored in any way).
Whats the best solution?
Edit:
I also tried to configure two entitymanager. One for the "internal" entities and for the "foreign" entities. Since all entities are linked to each other on some point, it is also not possible to have two separated manager don't knowing from each other entities.
App maker has relations to configure Primary and foreign key relation ship. I configure 1 to many relation, it creates parent column name in the child model.
I don't know how it works, it is taking the first column by default to save in the child model. I re ordered the fields but it is not changing the name and I have deleted the relation and re created but it is not reflecting.
Can any one explain how it works, Which field is configured as default primary key in the documentation also it is not mentioned any where.
You can change relation names on both sides of the relation at any time without re-creating it:
Drive Tables
For drive tables App Maker internally maintains _key, that is primary/foreign key SQL analogue. How the relation is handled under the hood is not exposed.
Cloud SQL
For cloud SQL things are little bit more transparent. For new models App Maker will automatically add id field that is primary key for SQL table and when you create a relation App Maker will automatically add foreign key column to the Model from the 'many' side.
I have a root in firebase like in the I am trying to enable user to delete an item on list. But user can give up his decision. When user give up this decision, I want to insert the deleted item again in the database. But, I want to insert with old firebase generated key, because I am using firebase push keys. Is that a bad practice. How firebase generate these keys? Does it checks every key on db and generate a new one? Is that any possibility, that key marked as removed and generated later for another item? Sorry for the language. It has been hard to express.
EDITED: I want to use the old key because, I am getting the data with orderByKey. I dont want to lose order.
How firebase generate these keys? Does it checks every key on db and generate a new one?
Whenever you use push on a Database Reference, a new data node is generated with a unique key that includes the server timestamp. These keys look like -KiGh_31GA20KabpZBfa.
Because of the timestamp, you can be sure that the given key will be unique, without having to check the other keys inside your database.
Is that any possibility, that key marked as removed and generated later for another item?
No, it is not possible that two keys will collide, regardless of wether one has been removed or not.
But, I want to insert with old firebase generated key, because I am using firebase push keys. Is that a bad practice
Unfortunately, you can't generate the same key twice by just using push. So, it is not possible to delete a node with a given key and then use push to insert it again at the same path with the same key, because push would generate a different and unique key.
Instead of this, if ordering by key is that important to you, and there's a possibility that a deleted node can be reinserted then I would recommend you to do one of the following :-
Either save the key on the client side when it's deleted from the database, and use it when you need to reinsert.
Or , maybe, have a "deleted-keys" path in your database and save the deleted keys there. Of course, with this approach, you'd need to store additional information to identify the data that the key corresponds to.
It all really depends on your use case.
Calling push() will generate a key for you.
If instead you use child(), you can determine they key/path yourself.
ref.child("yourvalue").setValue("setting custom key when pushing new data to firebase database");
https://firebase.googleblog.com/2015/02/the-2120-ways-to-ensure-unique_68.html
I have a application which I would like to add custom fields to the users table. I am not sure how to work after adding the columns. The columns are foreign keys to another table which holds more details for the user.
I am using Linq-to-SQL. So every time I add a user (using the membership functions i.e. Membership.CreateUser(..)) I end up calling another service to update the foreign keys on the users table.
Any better way of doing this will be highly appreciated.
Why are you adding foreign keys to the User table, pointing to another table with additional info??
I would do it the other way around:
create your own table UserInfo
create a FK column in UserInfo that points to the row in your ASP.NET membership User table
leave the system-provided User table alone - so you won't run into problems when e.g. an upgrade to the ASP.NET membership system is rolled out.....
I strongly recommend you not to extend secure tables such like Users, Membership, Profile. Better create another one table in your database (not secure database) with full info which you need. Call it 'User' with foreign key to 'Id' of table User in secure database.
I've started porting a .NET SQL Server application to LINQ to Entities. I have (among others...) one table called Users, and one called Time. Time is reported on a specific user (UserId), but it is also recorded which user made the report (InsertedByUserId) and possibly who has updated the Time since insert (UpdatedByUserId). This gives me three references to the table Users.
When I generate a .EDMX from this I get three references to the table Users: User, User1 and User2. Without manual edit I have no way of knowing which one refers to the UserId, InsertedByUserId or UpdatedByUserId field.
How do others solve this? Maybe it's not necessary to register ALL references, and stick with InsertedByUserId and UpdatedByUserId as ints?
(The manual edit wouldn't be a problem if the database were never updated, but as we make changes to the database every now and then we occasionally have to regenerate the .EMDX, thus removing all manual changes.)
Thanks in advance!
Jos,
Generally when I make my foreign keys, I name them accordingly. From the Entity designer you can differentiate between the different Navigation Properties (ie User, User1, User2) by looking at the FK association (as long as you named your foreign keys distinctly). For Instance I have a ModifiedById and CreatedById field in each table. Both fields reference my SystemUser table, My foreign keys are named like this: FK_[TableName]_SystemUser_CreatedBy and FK_[TableName]_SystemUser_ModifiedBy.
You should notice that in the Navigation properties you can see the Foreign key. You can also modify the name of the Navigation Property (which is in the Conceptual Side "CSDL portion" of the EDMX), and this change will stay when you update your EDMX from the database.