Closed Florian122 closed 4 years ago
@Florian122 Thanks. Does the table exist?
No, we took a look in the database but there is no such table. We tried to create the table by hand but it didn't work ether.
@Florian122 Are other tables auto created? What are your expectations? In what ways are your attempts to create the table failing?
You must provide full context and any supporting information. For example, is this the command model or query model? This is certainly not all the context we need, but there is no way to act on the information currently provided.
We created the tables with the migration script in the resource/db/migration
folder. Is there a way to generate them automatically?
We expected a mechanism that creates all the necessary tables for us.
The error occurs when we call the /portfolio GET
endpoint.
We are using the query model.
In general we created the project with the xoom-starter and used the implementations from the hello world example as template.
Thank you for the fast support! 👍
@danilo-ambrosio Do you have any ideas on this? I don't know exactly how to interpret this, either as a bug or as user misunderstanding. Should the database table be created on first run?
We have created the missing table in the database by hand with the following script:
(The Portfolio
consists of an id and a string 'owner')
CREATE TABLE tbl_portfoliodata (
id VARCHAR(128) PRIMARY KEY,
owner VARCHAR(256),
s_type VARCHAR(256),
s_type_version VARCHAR(256),
s_data VARCHAR(256),
s_data_version VARCHAR(256),
s_metadata_value VARCHAR(256),
s_metadata_value_version VARCHAR(256),
s_metadata_op VARCHAR(256),
s_id VARCHAR(256)
);
We got several error messages so we added the above listed 's_'-columns: Is this script okay like this?
After a POST request the PortfolioCreated
event gets saved in the vlingo_symbio_journal
table but the tbl_portfoliodata
table is still empty.
We have noticed that the merge
method in the PortfolioDataProjector
is never being called.
The query method (GET request) returns with an empty PortfolioData
object.
We expected to have the current state written into the tbl_portfoliodata
table.
@danilo-ambrosio
Hey @Florian122
Thanks for sharing the details. Today I'll take look at portfolio project and find out what's happening.
Let you know what I've got very soon.
Hi @danilo-ambrosio Where does this stand?
@VaughnVernon
Perhaps we'll need to fix something on vlingo-symbio-jdbc
. I noticed here is where the state store tables are created:
for (final String storeName : StateTypeStateStoreMap.allStoreNames()) {
final String tableName = tableNameFor(storeName);
try {
if (!tableExists(tableName)) {
createStateStoreTable(tableName);
}
}
....
However, StateTypeStateStoreMap
is never populated, so it's always empty. There is no occurrence of the StateTypeStateStoreMap.stateTypeToStoreName
invocation which is responsible for adding each state type for the table creation.
Any thoughts?
That should be part of the code generation.
Oh, I see. Should it be invoked in the *StateStoreProvider
classes?
Seems correct. You could see where it is in schemata, but what you indicate sounds best.
@Florian122
xoom-starter
is now fixed and tested for full table creation.
As a shortcut, if you want xoom
+ symbio
to take care of the table creation, check this small change I made on your portfolio project.
The auto creation of the table is working now, thanks for the fix!
But.. the table tbl_portfoliodata
is still empty after the post
call. The get
request returns with empty json.
I'm not sure if this was supposed to be fixed already.
Thank you for the help! 👍
@Florian122 Are you projecting the events into the query StateStore
?
When the project was generated there was a class called PlaceholderDefined
.
I assumed it is basically the PortfolioCreated
event, so i just renamed it.
Furthermore I assumed that this code would call all necessary functions in the background to trigger the PortfolioCreated
event:
Portfolio.defineWith(stage, "some name");
The event is persisted in the vlingo_symbio_journal
table but when I try to get the Object with:
private final PortfolioQueries portfolioQueries;
portfolioQueries.portfolioOf(id);
..the returned object is empty.
The PlaceholderDefined
was generated by an earlier version of the Starter, and you were correct to rename it. IIRC you must editor the code named AggregatenameProjection
, where Aggregatename
is probably Portfolio
. (I assume that is the name of the aggregate generated because you reference that name.) You will need to edit the PortfolioProjection
class and map the data from PortfolioCreated
into PortfolioData
and upsert that into the query model database. Once that is done you can query from that database.
@danilo-ambrosio Does the latest version of Starter generate the code to map the events to data and upsert the data into the query model database?
Yes, the most recent versions do it, @VaughnVernon.
I'm going to debug the Portfolio app and see what's happening.
@Florian122
I've found an issue regarding the ProjectionActor
generation. This is preventing the query model data from being stored.
I'm going to fix it. Keep you posted.
@danilo-ambrosio
Thank you for the effort! Do you have any news regarding the issue? We are looking forward to continue our work once everything is working.
@Florian122 Today @danilo-ambrosio and I discussed some significant simplifications of the projection generation. It should be ready very soon.
@Florian122
The starter
is now fixed in regard to Projection Actors
generation. You won't need to regenerate your project. Just consider the following changes I pushed on a fork so you can do the same in your project:
Thank you very much, the GET
request is working now!
@Florian122 Thanks for your patience! We've had a lot of conflicting priorities the past month and a few on the team were dealing with personal things.
@VaughnVernon and @danilo-ambrosio thanks for the fix. The team had on of those happy "fantastic, it works"-moments yesterday :-)
Hello, we have created a project for a portfolio. (Same project as #4)
We want to retrieve some data (get request). Some errors already got fixed by us. See this commit for more details.
Our latest error is the following one: