Develop Reference

how to create temp table using jdbc java

I need to create a temp table in order to store some ids which i will process under a later query. I am receiving error
com.microsoft.sqlserver.jdbc.SQLServerException: The statement did not return a result set.
When i execute my query for the creation of #temp table inside my sql. I don't need any resultset from this execution just need to create a temporary table with records. Please guide.
Code for my main query:
String queryTempTable = "SELECT TOP (2) A.Id INTO #temp\n" +
"FROM SALESDM.dbo.FactSales A\n" +
"INNER JOIN SALESDM2.dbo.FactSales B\n" +
"ON A.Id = B.Id\n" +
"AND (\n" +
" A.sysDateModified = B.sysDateModified\n" +
" OR A.Id = B.Id\n" +
" OR A.ModifiedDatetime = B.ModifiedDatetime\n" +
" )";
System.out.println(queryTempTable);
if (conn == null) {
System.out.println("Unable to create Connection");
} else {
Statement stmtTempTable = conn.createStatement();
stmtTempTable.executeQuery(queryTempTable);
}

You should use executeQuery only when you are retrieving data and want a ResultSet.
If you are modifying data, then you should use execute:
stmtTempTable.execute(queryTempTable);

If possible create a view using the given query? This will act as a temporary table. And call the view later based on your requirement.

Filter rows in DataSet using JPA/Hibernate

I have the following code which is used to retrieve data from multiple tables (using joins) and then mapping every row into a DTOList but I also need to apply filters based on user preferences: per table1.name or table2.name, table3, etc.
So I just want to know what would be the best way to do it in terms of performance and best practices;
retrieving all rows and then apply the filters with lambdas (easier)
change the query to a dynamic query with Criteria or something else?
Any other solution=?
#Repository
public class ArchiveRepository {
#Autowired
EntityManager em;
String queryStr = "select wsr.id as sampleid, s.id as slideid, tb.name as batchname, k.lot_number as kitlot, " +
" 'STRING' as slidetype, tb.worklist_name as worklist, wsr.final_call as results, " +
" wa.final_pattern_ids as patterns, 'edited/yesno' as edited, wsr.last_modified_by as user, wsr.last_modified_date as time " +
" from slide s " +
" left join table2 tb on s.test_batch_id = tb.id " +
" left join table3 k on tb.kit_lot_id = k.id " +
" left join table4 w on s.id = w.slide_id " +
" left join tabl5 pw on pw.well_id = w.id " +
" left join tabl6 cw on cw.well_id = w.id " +
" left join tabl7 wsr on wsr.patient_well_sample_id = pw.id or wsr.control_sample_id = cw.id " +
" left join (select * from *** (other subselect)) wa on wa.well_sample_id = wsr.**id or wa.well_sample_id = wsr.**id " +
"where tb.state = 'STATENEEDED'";
public ArchiveDataListDTO getArchiveData(){
Query query = em.createNativeQuery(queryStr);
ArchiveDataListDTO archiveDataListDTO = new ArchiveDataListDTO();
List<Object[]> resultL = (List<Object[]>)query.getResultList();
for( Object[] o : resultL){
archiveDataListDTO.addArchiveDataRow(
new ArchiveDataDTO((String)o[0], String.valueOf(o[1]), (String) o[2], (String) o[3], (String) o[4], (String) o[5],
(String) o[6], (String) o[7], (String) o[8], (String) o[9], (String) o[10]));
}
return archiveDataListDTO;
}
}
**
note I struggled some with the code cause I wanted to apply #sqlresultsetmapping to avoid manual results mapping but it just didn´t work, most of the examples out there are when you have an entity in the DB but in this case I retrieve from many tables.**
Thanks so much

2 .- change the query to a dynamic query with Criteria or something else?

I ended up creating the query on the fly; depending on the filters I get from UI i assemble the query with Java and send it to DB, it´s easier since this required many tables...

Spring JPA filter optional criteria in Query method

I want to filter out data from a database with few criteria (let's assume it is 8).
And below query method do this in a good way. But in fact, this criterias passed to the query method can be null (it means that should not be included to select query).
How I should handle this situation?
I really don't want to make n-methods to handle each case - it is not a good way.
#Query("SELECT NEW api.model.GeneralAnnouncementInfo(" +
"an.id, an.title, po.price, SUBSTRING(an.description, 1, 100), an.provider, an.creationDate, an.url, l.lessorType, concat(loc.city, ' ', loc.district)) " +
"FROM Announcement as an " +
"LEFT JOIN an.priceOffer as po " +
"LEFT JOIN an.lessor as l " +
"LEFT JOIN an.location as loc " +
"LEFT JOIN an.propertyData as pd " +
"WHERE l.lessorType = (:lessor) " +
"AND pd.roomNumber = (:rooms) " +
"AND pd.bathroomNumber = (:baths) " +
"AND pd.parkingAvailability = (:parking) " +
"AND pd.isSmokingAllowed = (:smokers) " +
"AND pd.isPetFriendly = (:pets) " +
"AND pd.area = (:realPrice) " +
"AND po.price = (:area) ")
Page<GeneralAnnouncementInfo> getAnnouncementsBySearchCriteria(Pageable pageable,
String lessor,
String rooms,
String baths,
String parking,
String smokers,
String pets,
String realPrice,
String area
);

I would recommend switching to the JPA Criteria API. It will give you the extra flexibility you are seeking (and which JPQL seems to be maxing out for your case). You can build your queries programmatically without any limitations and the best thing is that they get compiled; which means that no typos will survive (which are a nightmare to track in JPQL queries). Additionally you may want to use JPA metamodel classes; which add more robustness to your queries. At the end, your repository method would look something like this:
private EntityManager em;
private Page<GeneralAnnouncementInfo> getAnnouncementsBySearchCriteria(QueryParameters qParams) {
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<SampleEntity> criteria = cb.createQuery(GeneralAnnouncementInfo.class);
Root<GeneralAnnouncementInfo> root = criteria.from(GeneralAnnouncementInfo.class);
// Programmatically build query details (conditions, joins, aggregations, translation, etc)
// ...
// ...
// ...
return em.createQuery(criteria).getResultList();
}

Hibernate/JPA: Update then delete in one transaction

Is it possible to execute an update query then a delete query right after the update one in the same transaction? I'm trying to activate an account based on a token's hash and then remove that token in the same transaction.
transaction.begin();
entityManager
.createNativeQuery(
"UPDATE accounts AS ac "
+ "INNER JOIN account_tokens AS ak ON ac.id = ak.account_id "
+ "SET ac.account_state = "
+ "CASE "
+ "WHEN ac.account_state = 'AWAITING_ACTIVATION' THEN 'ACTIVATED' "
+ "END "
+ "WHERE ak.token_hash = :tokenHash")
.setParameter()
.executeUpdate();
em.createNativeQuery(
"DELETE FROM account_tokens AS ak "
+ "WHERE ak.token_hash = :tokenHash")
.setParameter()
.executeUpdate(); // delete
transaction.commit();

Yes, Use PL/SQL Procedure.
You can't reduce the number of queries - they all do different things - but you could reduce the number of round trips to the database and the number of parses by wrapping it all as a PLSQL function.
CREATE PROCEDURE s_u_d(a)
BEGIN
UPDATE tab_x SET tab_x.avalue=1 WHERE tab_x.another=a;
DELETE FROM tab_y WHERE tab_y.avalue=a;
SELECT *
FROM tab_x
WHERE tab_x.another=a;
END;

JPA EntityManager updates object before transaction has finished? [duplicate]

I have native query to run :
String sqlSelect =
"select r.id_roster as id, " +
"count(roster_cat.id_category), " +
" sum(case when roster_cat.id_category IN ( :categoryIds) then 1 else 0 end) as counter " +
"from roster r " +
"inner join roster_sa_categories roster_cat " +
"on r.id_roster = roster_cat.id_roster " +
"where r.day = :dayToLookFor " +
"and r.id_shop = :idShop " +
"group by r.id_roster " +
"having count(roster_cat.id_category) = :nrCategories " +
"and count(roster_cat.id_category) = counter" ;
Query selectRostersQuery = entityManager.createNativeQuery(sqlSelect);
selectRostersQuery.setParameter("categoryIds", Arrays.asList(categoryIds));
selectRostersQuery.setParameter("dayToLookFor", day.toString());
selectRostersQuery.setParameter("idShop", shopId);
selectRostersQuery.setParameter("nrCategories", categoryIds.length);
List<Integer> rosterIds = new ArrayList<>();
List<Object> result = (List<Object>) selectRostersQuery.getResultList();
For some reason Hibernate choses to do an update before executing the select and it is really interfering with my data
Hibernate: /* update domain.Roster */ update roster set day=?, employee_count=?, interval_end=?, interval_start=?, id_shop=? where id_roster=?
Hibernate: /* update Roster */ update roster set day=?, employee_count=?, interval_end=?, interval_start=?, id_shop=? where id_roster=?
Hibernate: /* dynamic native SQL query */ select r.id_roster as id, count(roster_cat.id_category),sum(case when roster_cat.id_category IN ( ?) then 1 else 0 end) as counter from roster r inner join roster_sa_categories
roster_cat on r.id_roster = roster_cat.id_roster where r.day = ? and r.id_shop = ? group by r.id_roster having count(roster_cat.id_category) = ? and count(roster_cat.id_category) = counter
Any help would be appreciated,Thank you

What you describe is precisely what Hibernate's FlushMode.AUTO implies.
Any modifications in the Persistence Context (1LC) at the time a query is executed will be automatically flushed prior to executing the query, guaranteeing that the results returned by the database match that which was cached by in-memory modifications.
If the query is going to return entities that you're seeing the update for, then you should likely re-evaluate your operations, making sure that the query fires prior to the update to avoid the flush operation, which can be quite expensive depending on the volume of entities in your Persistence Context.
If you are absolutely sure that the changes you're seeing flushed won't be returned by the query in question, you can always force the query not to cause a flush by setting the flush mode manually:
Query query = session.createQuery( ... );
query.setFlushMode( FlushMode.COMMIT );
List results = query.list();
But only do this if you're sure that the query wouldn't then be reading uncommitted changes as this can cause lots of problems and lead to long debug sessions to understand why changes are being inadvertantly lost by your application.