I want the primary key value of a table to start in this form in Laravel: 0001.
Here's what I did:
$table->id()->startingValue(0001);
But when a record is created, instead of the "0001" pattern it returns 1.
Yes, I know 0001 is the same thing as 1.
Any idea how I could make it retain that pattern or flip it around?
If you need to save it like that in de MySQL you'll need to use another type like string.
If it's only after db, laravel has mutators.
Related
I'm trying to select a key from my db and set its value in a json column with postgres keys are finishing with "_alert".
So in my bd I have a column named data as a json and i just want the keys finishing with "_alert" like "ram_alert", "temperatures_alert", "disk_alert", "cpu_alert".
So I need to get the key and the value to compare with the data I have in my backend app to validate if I need to update the value or dont.
How to do this?
I get all the keys doing select json_object_keys(data) from devices but how to get the key/value pair.. is there a way to use the "like" expression here?
First off, note that your current query will only work if you have one tuple in your 'devices' table. Try inserting another row and you'll get:
ERROR: cannot call json_object_keys on an array
If you're certain that you're only ever going to have ONE result from this table, then the following query should give you what you want:
SELECT key,value FROM devices,json_each(devices.data) where key ~ '_alert$';
I'd still throw something like "LIMIT 1" onto your query to be safe.
I'm trying to get my first select to work using selectall_hashref from the Perl DBI module. I've opened a connection to the database (MySQL) successfully. I'm getting an error when I execute the following:
$dbh->selectall_hashref('SELECT id FROM users WHERE login=?',undef,"myusername");
DBI::st=HASH(0x1505a60)->_prepare(...): attribute parameter 'myusername' is not a hash ref at /usr/lib/x86_64-linux-gnu/perl5/5.20/DBD/mysql.pm line 238.
My table should be able to support this query, it has an id column and login column for each user.
The examples I've found for selectall_hashref show the ? substitution parameter being passed as the third parameter. The DBI documentation says that the second and third arguments should be %attr and #bind_values but doesn't give much documentation about them or show working examples.
What is causing the error, and more importantly how do you actually use the %attr and #bind_values correctly?
If you want to store everything as an arrayref where each row is a hashref (which is what your comment seems to indicate), you can use the selectall_arrayref() method with the Slice attribute:
$dbh->selectall_arrayref('SELECT id FROM users WHERE login=?', {Slice => {}}, 'myusername');
It's a little weird, but here's how it works:
If $slice is a hash reference, fetchall_arrayref fetches each row as
a hash reference. If the $slice hash is empty then the keys in the
hashes have whatever name lettercase is returned by default. (See
"FetchHashKeyName" attribute.) If the $slice hash is not empty,
then it is used as a slice to select individual columns by name. The
values of the hash should be set to 1. The key names of the returned
hashes match the letter case of the names in the parameter hash,
regardless of the "FetchHashKeyName" attribute.
It's a good idea to set the FetchHashKeyName attribute on the database handle to make your hash key names consistent; I happen to like NAME_lc in my applications.
The methods expects key column as the second parameter and attributes ref is passed as third one. In the result it builds a hash with the specified column as a key. What you probably want, is selectall_arrayref:
$ dbh->selectall_arrayref('SELECT id FROM users WHERE login=?',undef,"myusername");
How do I capitalize all text in a column of data in an Access Query while keeping the name of the field the same?
I tried entering "SPEC: StrConv([SPEC],3), but I get an error that I have a circular argument (which, isn't too surprising). So how do I get around this?
Is there a totally different approach to capitalizing in queries?
Given: we have a field named [SPEC].
Problem: need query to grab [SPEC] and convert it to all caps, but
with the same field name
Added: We will call the table that holds the field [SPEC],
[tblTable]
Solution:
What we need to put in the query builder is the following:
SPEC: UCase([tblTable].[SPEC])
That way the machine can figure out that Query.SPEC isn't the same identifier as tblTable.SPEC
Equivalently:
SELECT UCase([tblNames].[FirstName]) AS FirstName
FROM tblNames;
How about using the Ucase function
Ucase(String)
i used mysql as my RDBMS and recently i have heard that you should not insert null in your DB,
i mean instead of having a lot of fields that they may or may not have value create a field and insert a data type like JSON in it.
e.g. i have table named as message
it contains fields like MessageType(it can be a map a video a photo or text,...) and it also has fields like(latitude,longitude for map),(photoid,photoPath,photoHash,... for photo),(videourl,videoHash,videoId,...) and so on. So when a message is type of text for example,it's field has value but i pass null in other fields like latitue,videourl,...
Is it a correct approach?Can you help me with better approach?
Regards
Instead of NULL try a different value like -1 or 0 or NA or a simple -
This might be an easy question for the sql pros here:
How could it possibly be that following queries with a database (one field varchar(30)), get different results:
SELECT field FROM table WHERE field=1234;
returns:
1234
1234
and
SELECT field FROM table WHERE field="1234";
returns:
1234
So, the first query seems to return the result 1234 two times, whether the second one returns the result only one time. The data in the database is unknown. To make it even more upset, the field "field" in the database has a unique key.
Thanks!
One possibility is that field is a string, and two rows contain these values
1234
1234.0
Both of these will compare true to numerical 1234.
http://dev.mysql.com/doc/refman/5.5/en/comparison-operators.html
First case "1234" is the correct one since the field value will not accept duplicated values.
To make sure there is no bug or system errors:
try to apply the same thing on a new table with few values in it. make the column Unique...and apply a query with "" and without "" .
The result should return One value only in the first case with "".
Regards