find_or_create_by updating id - mysql

I'm working on a RoR projects. I'm migrating a user table. Because the new dbase has a different set up and I want to seperate the login stuff from the personal/settings stuff I'm not importing the dbase; I migrate all attribute separately. I want to keep the old user id's. When I use user=User.new I can do user.id = migratee.user_id and I keep the same user_id. Unfortunately in the old table different users where registered with the same email address (don't ask why). Off course I don't want that so what I do in stead of user=User.new is user=User.find_or_create_by_email(migratee.email). This is going to lead to some problems, I know, since users with same email address will be overwritten. This is a problem I 'll deal with seperately. My problem is that when I do user.id = migratee.user_id after user=User.find_or_create_by_email(migratee.email) the old ID isn't migrated but a new auto-incrementing id is assigned. Anybody know how to avoid that?
Regards,
Rutger

I don't know how your query looks like. If you're doing an INSERT SELECT you can add a HAVING to filter existing email adresses. Otherwise you could do a GROUP BY email do only get one email.

If its a once off I would probably just turn off the auto_increment in your new mysql table id column until you have finished your migrations and then turn it back on or/ create another column called udid in the new database table (and then rename and delete the id col). Probably nicer ways to do it, but its fast and easy.

Related

How to change the values of two table automatically (MySQL)?

I have a database with two tables. The first one contains the user_name, user_password, user_email. The second one contains the user_name, user_age, user_description.
When a person finds the user he needs by the user_name, the script looks through the database using the user_name, to give out the information about certain user.
But if the person changes his user_name via preferences, the value changes only in the first table.
Question:
1) Is there a way to make the user_name in the second table change automatically? (To connect them some how)
I am using MySQL (phpMyAdmin).
This is just a simple example. In "real world" I am trying to manage more serious applications that have more tables. Is there an easier way than to create a separate php query for each table?
You could always create an AFTER UPDATE MySQL trigger targeting single rows for this. See the manual. It's probably not easier than using separate PHP queries for the tables, though. You don't need to spell them all out, just map up what needs to be synchronized when, and abstract your code.
However I'd recommend that you use a unique ID field for the user and only store the username in one of the tables -- and refer to the user with the ID under the hood of your code, and in both tables. Not a good idea to use something changeable as a unique identifier in your database design.

MySQL INSERT INGORE SELECT weird behaviour

I have been using a query to add editable profiles based on an original user table.
The original registration table has the fields, id - name - surname - username - password - email - confirmation
The profile has several more customizable fields, but the ones I am inserting into the profiles table from the users table is, id - name - email.
INSERT IGNORE INTO profile(cid,display_name,display_email)
SELECT id,name,email FROM users
This used to work for a couple of years now, but recently I noticed that the profiles table has topped inserting profiles when users register. When I run the query in phpmyadmin it just says 0 rows inserted.
Can someone please help me to figure out why this is happening? Updates to MySQL that I missed or something :(
Solved the problem.
It would seem my host for some reason, during upgrades changed my table field id on the profiles table to a defined value of 0.
I edited the structured and set it back to auto_increment. Which was the reason the query stopped adding the new values.
Thank you to everyone that questioned me, it pointed me towards the problem and helped to resolve this issue.

Is it possible to have a MYSQL field that always is equal to another?

I'm using some code written for once place in another, which I guess is the start of my problems.
In my ideally unchangeable existing code I have a query something like:
SELECT username FROM users
However, in the new database, there is no username field, but there is an email address.
I'd like to change the new database somehow so that when I ask for username I get back the email.
I understand that I can just make a new field and manually populate it when the email updates, but I'd really like some kind of alias so that both codebases can work without modification.
Is this possible?
You could create a view:
CREATE VIEW v_users AS
SELECT email AS username
FROM users
Since this is over just one table, you could even use it for updates and inserts as well as queries (if you are using a relatively new version of MySQL)
You could even create all the views in a separate database - that way they could have the same names as the original tables:
CREATE VIEW db2.users AS
SELECT email AS username
FROM db1.users
You could add the username field and keep it aligned to the e-mail address through a trigger, or you could use a view of the users table.
Triggers: http://dev.mysql.com/doc/refman/5.5/en/create-trigger.html
Views: http://dev.mysql.com/doc/refman/5.5/en/create-view.html
Unfortunately, MySQL does not support Computed Columns.
There are a few workarounds from what I found when googling this matter, but you're probably best off just copying the values, or using a trigger which automatically updates it.

Group data in mysql

Isn't it possible to store table in table?
let's say I have a list of users and every user can be admin in one or more servers.
If user an admin, then I need to store "Expired", "Type" columns for every server.
So how better to store this information?
I don't want to make columns like this:
Server1_Expired Server1_Type Server2_Expired Server2_Type etc.
Also I can create tables for every server and store the same content, but it looks ridiculous.
I'm sorry if it's hard to understand, I just don't know how to explain else.
Please try understand me :)
Create a table called admin_servers and have a few columns... id, admin_id, server_id, type, expired
This table creates a link between an admin and a server. For each row, you also have a type and expired value.

Keeping id's unique Client Side and Server Side

i am scrubbing my head now for hours to solve thw following situation:
Several Html Forms on a webpage are identified by an id. Users can create forms on the clients side themselves and fill in data. How can I guarantee that the id of the form the user generates is unique and that there doesnt occure any collision in the saving process because the same id was generated by the client of someone else.
The problems/questions:
A random function on the client side could return identical id's on two clients
Looking up the SQL table for free id wouldnt solve the problem
Autoincrement a new id would complicate the whole process because DOM id and SQL id differ so we come to the next point:
A "left join" to combine dom_id and user_id to identify the forms in the database looks like a performance killer because i expect these tables will be huge
The question (formed as simple as i can):
Is there a way that the client can create/fetch a unique id which will be later used as the primary key for a database entry without any collisions? Whats the best practice?
My current solution (bad):
No unique id's at all to identify the forms. Always a combination through a left join to identify the forms generated by the specific user. But what happens if the user says: Delete my account (and my user_id) but leave the data on the server. I would loose the user id and this query qouldn't work anymore...
I am really sorry that i couldn't explain it in another way. But i hope someone understood what i am faced with and could give me at least a hint
THANK YOU VERY MUCH!
GUIDs (Globally Unique IDentifiers) might help. See http://en.wikipedia.org/wiki/GUID
For each form the client could generate a new GUID. Theoretically it should be unique.
I just don't show IDs to the user until they've submitted something, at which point they get to see the generated auto-increment id. It keeps things simple. If you however really need it, you could use a sequence table, but it has some caveats which make me advise against it:
CREATE TABLE sequence (id integer default 0, sequencename varchar(32));
Incrementing:
UPDATE sequence
SET id = #generated := id + 1
WHERE sequencename = 'yoursequencename';
Getting:
SELECT #generated;