[
https://issues.apache.org/jira/browse/ISIS-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14106968#comment-14106968
]
Dan Haywood commented on ISIS-766:
----------------------------------
Hi Ranganath,
OK, here's where I'm at. I've:
* imported your project into IDE
* created a blank database in PostgreSQL using info from persistor.properties
(DB: ods_master_bby, user odsadm/odsadm
* loaded in your database dump using psql < ODS_MASTER_BBY.backup
- there were a few warnings/errors, didn't investigate, but mostly seemed to
load OK
* edited persistor.properties to point to port 5432 rather than 5433
* edited shiro.ini for port number
* edited shiro.ini because couldn't find users table (which I'm guessing is a
view), so added:
jdbcRealm.authenticationQuery = select password from gemsods.users where
username = ?;
* edited the odsmaster.properties file to change the uploadPath from the E:
drive to C: drive.
With all that done, I could run the app.
I uploaded the supplied XLS, and (after waiting for a few minutes to process)
it threw an exception, because of:
javax.jdo.JDODataStoreException: Update of object
"com.wipro.wess.ods.asset.OmAsset@15d9035f" using statement "UPDATE
gemsods."om_asset" SET "changedate"=?,"location_uid"=?,"loc_org_id"=? WHERE
"asset_uid"=? AND "org_id"=?" failed : org.postgresql.util.PSQLException:
ERROR: type "gemsods.audit_logged_actions" does not exist
Where: compilation of PL/pgSQL function "audit_ods_master_changes_func" near
line 3
at
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2102)
at
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1835)
at
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:500)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:388)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:334)
at
org.datanucleus.store.rdbms.datasource.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
at
org.datanucleus.store.rdbms.datasource.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
Poking around a bit more I discovered
dom/scripts/Postgresql_Audit_trigger_91plus.sql, which looked like it contained
the missing schema, but it failed to load... something to do with "hstore":
[snip]
ods_master_bby(# row_data hstore,
ods_master_bby(# changed_fields hstore,
ods_master_bby(# statement_only BOOLEAN NOT NULL
ods_master_bby(# );
NOTICE: CREATE TABLE will create implicit sequence "audit_logged_actions_event_
id_seq1" for serial column "audit_logged_actions.event_id"
ERROR: type "hstore" does not exist
LINE 16: row_data hstore,
>From the first line in this SQL I'm guessing that "hstore" is some sort of
>extension that is non-standard and I don't have in my PostgreSQL.
I also tried commenting out the call to do the processing:
// provisionSheetUpload.upload(file);
// boolean uploaded =
ProvisionSheetProcessor.process(provisionSheetUpload, this.locationMap,
this.container);
boolean uploaded =true;
and the method ran fine, returning a single OmSite instance.
So far this has taken me well over an hour, but am no nearer figuring out the
issue. I hope you can see why we asked for a small reproducable example of the
problem; this is far too much work for me to do.
If you can tell me how to get the auditing thing sorted, I'll spend some a bit
more time on it. But not much more.
~~~~~~~~~
Meanwhile, I have a few suggestions on how to improve your code:
1. in the upload method, you're calling static methods on
ProvisionSheetProcessor.process. As I'm sure you are aware, this isn't
thread-safe so won't work for multiple users. Can't see any reason why you are
using static methods here.
2. Not sure why you are writing the uploaded file to the disk; I'm sure that
you could figure out a way to process it from the bytes.
3. Since you are writing the uploaded file to disk, it is hard-coded to always
write to a single file. It should instead use a temporary file (to be
threadsafe).
4. It took several minutes to do the upload (before it eventually failed). It
might make more sense to do this as a background command, to be invoked by the
scheduler. Then, mail the user when done.
5. There are too many menu items, so they overflow. It is possible to move
multiple menu items onto a single "Foo" service by using
@MemberOrder(name="Foo", sequence="xxx") as the annotation for any service
actions. For example, Estatio moves a lot of menu items for reference data
entities to a single "Admin" service.
6. The UI of the OmSite that was returned from the upload action could be
improved substantially. Use member groups to group multiple properties
together, and maybe move the collections to the bottom. The @MemberOrder and
@MemberGroupLayout annotations, or alternatively the .layout.json files, allow
this to be done.
7. in some entities I saw:
public void jdoPreStore() {
this.setChangeDate(new Date());
this.setConfigUser(this.container.getUser().getName());
}
+1 for using JDO callbacks, however this particular callback is a
cross-cutting concern and so could probably be handled using a single service
that registers on behalf of all entities. Something like:
@DomainService // 1.6.0
public class UpdateDateAndUserOnChangeService implements
StoreLifecycleListener {
public void preStore (InstanceLifecycleEvent event) {
Object pojo = event.getPersistentInstance();
if(pojo instanceof UpdateableObject) { // make entities implement
this...
UpdateableObject uo = (UpdateableObject)pojo;
uo.setChangeDate(...);
uo.setConfigUser(this.container.getUser().getName());
}
}
@PostConstruct
public void init() {
isisJdoSupport.getJdoPersistenceManager().getPersistenceManagerFactory().addInstanceLifecycleListener(this,
null);
}
@Inject
private IsisJdoSupport isisJdoSupport;
}
8. Use services to break out dependencies. I would move
ProvisionSheetProcessor.process into its own service so that it can be unit and
integration tested separately.
9. Use the ClockService rather than simply using new Date().
> ISIS Service / ViewModel method calling twice when this method processing
> BLOB type
> -----------------------------------------------------------------------------------
>
> Key: ISIS-766
> URL: https://issues.apache.org/jira/browse/ISIS-766
> Project: Isis
> Issue Type: Bug
> Components: Viewer: Wicket
> Affects Versions: viewer-wicket-1.4.1
> Reporter: Ranganath Chittari
> Assignee: Dan Haywood
> Priority: Blocker
> Fix For: viewer-wicket-1.7.0
>
> Attachments: BBY Provisioning Template V1 12.3.xlsx,
> Behaviour-Rejected-Error.log, Files.zip, Upload-Invocation-Failed.log, dom.zip
>
>
> Isis service or ViewModel method getting called twice.
> For ex:
> I have one Hidden service which has lookup method with @HomePage returning a
> ViewModel instance using newViewModelInstance(..) method and that renders one
> action method taking Blob parameter as button. It's basically upload button
> to upload a file. When I click on upload button, this upload method called
> and completed the uploading and again getting called second time by itself.
> And this is inconsistent behavior. Some times its working(meaning called only
> once) but some other times it's not.
> So I tried this upload action with service class by extending AbstractService
> which appears in the menu with Upload action. Here also it's the same issue.
> Please find attached files in this Jira as I don't have GIT client to push
> the files in github
> BR
> Ranganath Varma
--
This message was sent by Atlassian JIRA
(v6.2#6252)
