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.
Related
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.
I am on jooq queries now...I feel the SQL queries looks more readable and maintainable and why we need to use JOOQ instead of using native SQL queries.
Can someone explains few reason for using the same?
Thanks.
Here are the top value propositions that you will never get with native (string based) SQL:
Dynamic SQL is what jOOQ is really really good at. You can compose the most complex queries dynamically based on user input, configuration, etc. and still be sure that the query will run correctly.
An often underestimated effect of dynamic SQL is the fact that you will be able to think of SQL as an algebra, because instead of writing difficult to compose native SQL syntax (with all the keywords, and weird parenthesis rules, etc.), you can think in terms of expression trees, because you're effectively building an expression tree for your queries. Not only will this allow you to implement more sophisticated features, such as SQL transformation for multi tenancy or row level security, but every day things like transforming a set of values into a SQL set operation
Vendor agnosticity. As soon as you have to support more than one SQL dialect, writing SQL manually is close to impossible because of the many subtle differences in dialects. The jOOQ documentation illustrates this e.g. with the LIMIT clause. Once this is a problem you have, you have to use either JPA (much restricted query language: JPQL) or jOOQ (almost no limitations with respect to SQL usage).
Type safety. Now, you will get type safety when you write views and stored procedures as well, but very often, you want to run ad-hoc queries from Java, and there is no guarantee about table names, column names, column data types, or syntax correctness when you do SQL in a string based fashion, e.g. using JDBC or JdbcTemplate, etc. By the way: jOOQ encourages you to use as many views and stored procedures as you want. They fit perfectly in the jOOQ paradigm.
Code generation. Which leads to more type safety. Your database schema becomes part of your client code. Your client code no longer compiles when your queries are incorrect. Imagine someone renaming a column and forgetting to refactor the 20 queries that use it. IDEs only provide some degree of safety when writing the query for the first time, they don't help you when you refactor your schema. With jOOQ, your build fails and you can fix the problem long before you go into production.
Documentation. The generated code also acts as documentation for your schema. Comments on your tables, columns turn into Javadoc, which you can introspect in your client language, without the need for looking them up in the server.
Data type bindings are very easy with jOOQ. Imagine using a library of 100s of stored procedures. Not only will you be able to access them type safely (through code generation), as if they were actual Java code, but you don't have to worry about the tedious and useless activity of binding each single in and out parameter to a type and value.
There are a ton of more advanced features derived from the above, such as:
The availability of a parser and by consequence the possibility of translating SQL.
Schema management tools, such as diffing two schema versions
Basic ActiveRecord support, including some nice things like optimistic locking.
Synthetic SQL features like type safe implicit JOIN
Query By Example.
A nice integration in Java streams or reactive streams.
Some more advanced SQL transformations (this is work in progress).
Export and import functionality
Simple JDBC mocking functionality, including a file based database mock.
Diagnostics
And, if you occasionally think something is much simpler to do with plain native SQL, then just:
Use plain native SQL, also in jOOQ
Disclaimer: As I work for the vendor, I'm obviously biased.
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.
Our CREATE TABLE statement uses a user defined type (the ones you create with CREATE TYPE). Is this supported in the stress tool in 2.1? It doesn't look that way if I look into StressProfile.java
Also I was wondering if there was a way to stress test multiple tables at the same time.
In my experience that is not possible. While using cassandra-stress (2.1) I furthermore noticed that not only UDTs but the CQL data type map is not supported as well.
I ended up to create one user profile for each table and dropped the map-typed columns from the table while stressing.
I have a question about querying CouchDB.
I have a query that generates a set of outputs. These outputs are also the result of another query.
I want to define a CouchDB view permitting to get all the outputs (and the inputs of a specific document). Is it possible to get the results of a map function and consider them as un input of another map function ?
In SPARQL, I have do this query, it is modeled as follow :
SELECT ?linkedAction
WHERE { ?action nova:hasOutput ``doc-02-10-C''.
?action (nova:hasInput/^nova:hasOutput)* ?linkedAction.
}
Is it possible to do that in map/reduce ?
Best Regards.
Amin
You can try Couch-Incarnate.
Or use Cloudant chained mapreduce views (hopefully it will be integrated in CouchDB).
No, each view index is completely isolated from other views. (and other databases for that matter) CouchDB's incremental view updates would be impossible to keep efficient when changes from one view can affect another. You'll need to perform this kind of additional processing in your application layer.