Currently Save() API offers upsert behaviour when passing in a collection but is there anyway to make it work when inserting from another table?
The way I upsert with raw PostgreSQL is like this:
INSERT INTO customers (name, email)
SELECT name, email FROM other_table
ON CONFLICT (name)
DO
UPDATE SET email = EXCLUDED.email;
OrmLite supports ON CONFLICT but I can't see any way to chain that into an update using EXCLUDED.
Is there a way to achieve this type of functionality with the fluent API without reading the collection into memory?
There's no typed API support for this in OrmLite and likely wont be as it's nigh impossible to provide a good typed cross-platform abstraction to handle the different capabilities & permutations of this feature in RDBMS's that support Upsert.
You're going to have to execute the Upsert SQL Query you want using OrmLite Custom SQL APIs which you can use with OrmLite's typed Column<T> and Table<T> APIs to include typed Table & Column references in adhoc SQL.
Related
I know the question was asked before, but at the time it was, we had EF Core 2.x. The short answer was "no you can't" and obviously, not very helpful.
The other answers involved ugly hacks like changing migration files after they were created by the tool.
I make an application Code First. I have my models created with lot's of foreign keys and database joins in mind.
But here comes the unpleasant surprise (I'm a little new to EF): those joins written in LINQ are pretty slow, as a matter of fact they do not produce database join, but fetch whole tables instead.
Of course it's totally unacceptable, I import an old database with millions of records, with the joins I get results in milliseconds, without I get couple of seconds lags - on my very fast internet connection (in real world scenario it would be much worse).
I need views, and AFAIK EF won't create them for me, is it STILL true for EF 3.0?
Then, what would be the best and the most clean way to create views in SQL and to make entities for them? I mean - considering the situation the database models would change over time, and the database structure would have to be updated.
Well, I would prefer doing my joins not in SQL views, just have queries returned "JOIN" statement results. Especially some not obvious joins. Lets say table B has a column being a foreign key referencing table A. I want to get results from table A joining B for details. With normal SQL JOIN performance.
I checked the database: there is no significant performance difference between "select * from A" and "select * from A join B...". In LINQ - the difference is huge.
I figured out that in Code First database views are redundant.
The "views" can be created as models (ordinary classes) having a field or a property set to joined entity. I use private fields for that purpose. Then I use LINQ Join() to create my view entity. The query may refer ONLY to the fields set to joined entities, nothing else. Such query, if written properly translates clearly to SQL JOIN and works with full speed. In my application it's equivalent of a database view.
Why private fields and not properties, you may ask. Maybe because joined entities are "implementation details", but another reason is my presentation code uses reflection to operate on entity public properties, it's good to have those entities hidden from it. Otherwise I would probably need to use attributes to hide those "columns".
BTW, such views can be ordered with OrderBy(), filtered with Where() at virtually no cost. The constraint is to maintain the collection's IQueryable interface, never refer joined entities indirectly. So even if X refers to A.B, never refer X in a LINQ query, always A.B where A is direct entity reference assigned in the Join() query.
To build dynamic queries at runtime one must use expressions.
This set of properties of EF Core 3.0 allows to build a database application without using SQL, but with the full SQL speed maintained. However, the database / entity structure must be relatively simple to achieve that.
I have some MSSQL tables created by ServiceStack.OrmLite and I'd like to programmatically change the types of some some columns or perhaps drop and re-create some of them (with different types). The problem is that some of them may be used in indexes (also created by OrmLite from [Index]/[CompositeIndex] attributes). Is there an easy way to ask OrmLite to drop and to create all indexes used by particular column?
I noticed there is IDbConnection.CreateIndex, but this probably won't work for composite indexes. There is also IDbConnection.DropIndex, but that requires the name of the index, which I don't have.
There's no API that says "drop/re-create Indexes for a column", the only DDL APIs OrmLite offers are on the OrmLiteSchemaModifyApi class.
You'll need to use db.ExecuteSql for any other table modifications you want to perform programmatically.
I evaluating CouchDB & I'm wondering whether it's possible to achieve the following functionality.
I'm planning to develop a web application and the app should allow a 'parent' table and derivatives of this table. The parent table will contains all the fields (master table) and the user will selectively choose fields, which should be saved as separate tables.
My queries are as follows:
Is it possible to save different versions of the same table using CouchDB?
Is there an alternative to creating child tables (and clutter the database)?
I'm new to NoSQL databases and am evaluating CouchDB because it supports JSON out of the box and this format seems to fit the application very well.
If there are alternatives to NOT save the derivatives as separate tables, the better will the application be. Any ideas how I could achieve this?
Thanks in advance.
CouchDB is a document oriented database which means you cannot talk in terms of tables. There are only documents. The _rev (or revision ID) describes a version of a document.
In CouchDB, there are 2 ways to achieve relationships.
Use separate documents
Use an embedded array
If you do not prefer to clutter your database, you can choose to use option (2) by using an embedded array.
This gives you the ability to have cascade delete functionality as well for free.
Mongodb doesn't support multi collection query, like "left join" in SQL. It only support "populate", but it can't populate subdocument and find parent-document at the same time.
One line query code in SQL, while mongodb user has to query every parent document _id himself.
I have run into these question:
How to populate other collection's subdocument in mongoose?
https://stackoverflow.com/questions/24075910/mongoose-cant-update-or-insert-subdocuments-array
I finally query every _id by myself in a forEach loop.
Is there a plugin to query multi collection like "join"? Or is there any better solution to multi collection query?
Is there a plugin to query multi collection like "join"?
Some DB products have plug-ins that provide extra features, like PostGIS for Postgres. MongoDB does not have such a plug-in for JOINs. It is unlikely that such a plug-in will ever exist because MongoDB is designed not to have join support.
mongoose...
So the one spot where there is "join-like" support are the drivers. Some drivers and wrappers (like Morphia), have support for opening a document and its related sub-documents from a different collection. However, in this case, the driver/tool is simply doing the work of performing multiple queries on your behalf.
This can easily generate too many queries.
Or is there any better solution to multi collection query?
The only solution provided wholly within MongoDB is going to be via the Map / Reduce or Aggregation Framework tools. Even with these tools, you are likely going to have to do multiple passes of the data and then write some scripts to stitch together this data. This will be a lot of work, but you're trying to do something that MongoDB doesn't like to do, so that's expected.
Another solution would be to leverage Hadoop. MongoDB has a Hadoop plug-in so you can run Hadoop over the existing data. Add in some Hadoop query tools like Hive and then you can get an SQL-Like query over the top. This will also be a lot of work, but will enable to run all sorts of SQL-like queries.
i just started discovering serviceStack ORMlite , and i am trying to figure out how to do batch inserts. Are there any example of this anywhere ?
Thanks in advance
There's currently no built-in support take take advantage of custom RDBMS's support for this feature. E.g. MySQL's Batch Insert support.
The Insert and InsertAll methods in OrmLite do already accept multiple entities, but they're executed individually.
Depending on the database (that support batch insert via SQL) you can execute custom arbitrary SQL by using IDbCommand.ExecuteSql method.