I am using OrientDB for the first time. I read that this database operates in a schema less mode.
Although there seems to be some confusion between Field and Property. What is the difference between these two?
The ALTER command does work on fields but fields are shown under the property name in OrientDB studio in query results. Field operations are done through UPDATE. Am I missing something. Please clarify.
The field and property are the same thing in OrientDB.
When you use UPDATE you should not specify the word property or field, the property is just used in ALTER queries, for example ALTER PROPETY, see:
https://orientdb.com/docs/last/SQL-Alter-Property.html
and
https://orientdb.com/docs/last/SQL-Update.html
Related
I'm interested in using the following audit mechanism in an existing PostgreSQL database.
http://wiki.postgresql.org/wiki/Audit_trigger
but, would like (if possible) to make one modification. I would also like to log the primary_key's value where it could be queried later. So, I would like to add a field named something like "record_id" to the "logged_actions" table. The problem is that every table in the existing database has a different primary key fieldname. The good news is that the database has a very consistent naming convention. It's always, _id. So, if a table was named "employee", the primary key is "employee_id".
Is there anyway to do this? basically, I need something like OLD.FieldByName(x) or OLD[x] to get value out of the id field to put into the record_id field in the new audit record.
I do understand that I could just create a separate, custom trigger for each table that I want to keep track of, but it would be nice to have it be generic.
edit: I also understand that the key value does get logged in either the old/new data fields. But, what I would like would be to make querying for the history easier and more efficient. In other words,
select * from audit.logged_actions where table_name = 'xxxx' and record_id = 12345;
another edit: I'm using PostgreSQL 9.1
Thanks!
You didn't mention your version of PostgreSQL, which is very important when writing answers to questions like this.
If you're running PostgreSQL 9.0 or newer (or able to upgrade) you can use this approach as documented by Pavel:
http://okbob.blogspot.com/2009/10/dynamic-access-to-record-fields-in.html
In general, what you want is to reference a dynamically named field in a record-typed PL/PgSQL variable like 'NEW' or 'OLD'. This has historically been annoyingly hard, and is still awkward but is at least possible in 9.0.
Your other alternative - which may be simpler - is to write your audit triggers in plperlu, where dynamic field references are trivial.
I am looking a way to remove a propertyKey in the schema. The documentation here explains how to add properties but no information about the removal. Does that mean that it is not possible?
Since DataStax relies on Cassandra that supports table altering I guess there is some way to achieve that, otherwise how to deal with dynamic schemas where properties can be added or removed?
Edit: For more clarity I want to remove the property both in the schema and in the data. Exactly like the ALTER DROP in SQL:
ALTER TABLE table_name
DROP COLUMN column_name
The DSE Graph reference for dropping data, schema or graphs is: http://docs.datastax.com/en/latest-dse/datastax_enterprise/graph/using/dropSchemaDataStudio.html
As DSE Graph is built on the standards of TinkerPop, you can also leverage the TinkerPop 3 API references here - http://tinkerpop.apache.org/docs/current/reference/#_tinkerpop3.
For this item, i believe you are looking for .drop(). http://tinkerpop.apache.org/docs/current/reference/#drop-step
From the above link, if you want to remove a property, do this: .properties("X").drop()
I am trying to find a way to only populate a property of my entity class, if the column exists in the query?
When I execute a query using DbSet.SqlQuery and returning the column (which is an alias) populated, everything is fine. But when using the built in functionality such as All(), Find(), ToArray() etc, it expects that column to be in the dataset.
Is there a way (without having to write all of the supporting queries manually) to mark a property in my entity class, as optional.
It is currently marked as a nullable DateTime but the framework still complains it does not exist when using the built in functionality.
Any suggestions would be great!
Cheers
No, because they have to build the SQL query. It doesn't matter if a column is nullable or not, what matters is that when they build the query, if that column does not exist, then the database will likely throw an error complaining that the column does not exist.
The only way around it is to not map it, or to query the schema when mapping and conditionally map the property (though I wouldn't recommend that).
(Table)File has many (Table)Words
FK Words.file_id related to a single File.id
Default value of Words.frame is equal to File.frame for that PK/FK
Does this type of default relationship have a name? Examples on getting this setup? (MySQL)
Edit
The reason for this is that words may have the same frame as the file and if they do, we want to use that default, however some may not and need to be set manually. Is this really bad practice to handle it this way as described in one of the answers? Any improvement suggestions?
You may want to use a Trigger. You should be able to mimick the "default value" of Words.frame to be based on the value of another field from the File table.
It doesn't have a name, but feels like denormalization / data duplication to me.
#Daniel Vassallo suggests an insert trigger for this, and I think that would be the best approach as well if this is really what you need.
I'm sure this might be quite common query but couldn't find good answer as for now.
Here is my question:
I've got a table named Contacts with varchar column Title. Now in the middle of development I want to replace field Title with TitleID which is foreign key to ContactTitles table. At the moment table Contacts has over 60 dependencies (other tables, views functions).
How can I do that the safest and easiest way?
We use: MSSQL 2005, data has already been migrated, just want to change schema.
Edit:
Thanks to All for quick replay.
Like it was mentioned Contacts table has over 60 dependents, but when following query was run, only 5 of them use Title column. Migration script was run, so no data changes required.
/*gets all objects which use specified column */
SELECT Name
FROM syscomments sc
JOIN sysobjects so ON sc.id = so.id
WHERE TEXT LIKE '%Title%' AND TEXT LIKE '%TitleID%'
Then I went through those 5 views and updated them manually.
Use refactoring methods. Start off by creating a new field called TitleID, then copy all the titles into the ContactTitles table. Then, one by one, update each of the dependencies to use the TitleID field. Just make sure you've still got a working system after each step.
If the data is going to be changing, you'll have to be careful and make sure that any changes to the Title column also change the ContactTitles table. You'll only have to keep them in sync while you're doing the refactoring.
Edit: There's even a book about it! Refactoring Databases.
As others pointed out it depends on your RDBMS.
There are two approaches:
make a change to the table and fix all dependencies
make a view that you can use instead of direct access to the table (this can guard you against future changes in the underlying core table(s), but you might loose some update functionality, depending on your DBMS)
For Microsoft SQL Server Redgate have a (not free) product that can help with this refactoring http://www.red-gate.com/products/sql_refactor/index.htm
In the past I have managed to do this quite easily (if primitively) by simply getting a list of things to review
SELECT * FROM sys.objects
WHERE OBJECT_DEFINITION(OBJECT_ID) LIKE '%Contacts%'
(and possibly taking dependencies information into account and filtering by object type)
Scripting all the ones of interest in Management Studio then simply going down the list and reviewing them all and changing the CREATE to ALTER. It should be quite a simple and repetitive change even for 60 possible dependencies. Additionally if you are referring to a non existent column you should get an error message when you run the script to ALTER.
If you use * in your queries or adhoc SQL in your applications obviously things may be a bit more difficult.
Use SP_Depend 'Table Name' to check the Dependencies of the table
and then Use the SP_Rename to Rename the Column Name which is very useful.
sp_rename automatically renames the associated index whenever a PRIMARY KEY or UNIQUE constraint is renamed. If a renamed index is tied to a PRIMARY KEY constraint, the PRIMARY KEY constraint is also automatically renamed by sp_rename.
and then start Updating the Procedure and Functions one by one there is no other good option for change like this if you found then tell me too.