I just hit an interesting wall. We are in the process of developing a pretty reasonable sized application that has a ton of historical data. The plan is to use materialized views and do nightly/weekly refreshes as applicable to help reduce the impact on the server for large data set reports.
I know that in Cake 2, I could just define a new view by creating the appropriate model and the running with it. I could even bake the model as a starting point.
However, with Cake 4, I am getting an error when I try to use it. Specifically the error that gets raised is:
“Cannot describe v_12month_summary. It has 0 columns.”
This happens whether I bake, or manually create the entity and table model files.
Is there a way to use materialized, or even regular views, with CakePHP 4? Essentially, I would like to be able to:
$yearSummary = $this->fetchTable('V12monthSummary')->find()->where(['month'=>6,'year'=>2021'])
Related
Im currently developing a servlet homepage (spring + hibernate + mysql).
Im at the moment using the Hibernate property hibernate.hbm2ddl.auto set to update.
This is working fine and Hibernate creates and updates my tables.
However, Ive have read on multiple places that this is not recommended in production and that it is unsafe.
But if I dont put this option my tables is not created, and I really don't want to create my tabels manually on the server. I got limited time working on this alone.
How is this usually done? It's seems like it is quite much work to add all tables manually imo.
In production, you typically have already existing tables with a large amount of data that you don't want to lose, and that you want to migrate to the new schema. Hibernate can't do that automagically for you. It doesn't know that the data that was previously in column A must now be in the new column B.
So you'll need to create a migration script. Of course, you can use Hibernate to generate the new schema for you in development, see what the differences with the old schema are, and create your script thanks to that. But yes, having an app in production and migrate it needs some work to be done.
Some days I love my dba's, and then there is today...
In a Grails app, we use the database-migration plugin (based on Liquibase) to handle migrations etc.
All works lovely.
I have been informed that there is a set of db administrative meta data that we must support on every table. This information has zero use to the app.
Now, I can easily update my models to accommodate this. But that answer is ugly.
The problem is now at each migration, Liquibase/database-migration plugin, complains about the schema and the model being out of sync.
Is there anyway to tell Liquibase (or GORM) that columns x,y,z are to be ignored?
What I am trying to avoid is changesets like this:
changeSet(author: "cwright (generated)", id: "1333733941347-5") {
dropColumn(columnName: "BUILD_MONTH", tableName: "ASSIGNMENT") }
Which tries to bring the schema back in line with the model. Being able to annotate those columns as not applying to the model would be a good thing.
Sadly, you're probably better off defining your own mapping block and taking control of the Data Mapper (what Hibernate essentially is) yourself at this point. If you need to take control of the way the database-integration plugin handles migrations, you might wanna look at the source or raise an issue on the JIRA. Naively, mapping your columns explicitly in the domain model should allow you to bypass unnecessary columns from the DB.
My RCP application contains 5 views which fill contents via database queries.
The problem is that the application start completely depends on database queries. In addition, if underlying db is closed the application start time takes too long.
What is the best practice for eclipse rcp views that use db as content source?
Is using a separate thread for filling views be a solution?
Move all your view updating code into an UIJob, then schedule it. User can find the progress of these tasks in the progress view if it is included in your RCP.
In addition, one UIJob takes care one view.
We are working on a POC where we have following architecture (MVVM),
WPF(Client) + WCF + Model(DataAccess)+ ADO.Net Entity Framework 4.0 (with SQL Server 2008 R2 as DB)
All are different projects.
In the DataAccess layer we have created different Entity Models(edmx) based on the functionality. The tables under perticular flow are grouped and created different entity models. We are using self tracking entities to and fro to communicate with the WPF client through wcf service. For Single model everything works fine. But when we created a Multiple models then few issues started coming. Mutliple models have few duplicate tables/entities. Two probels are,
1) When we try to access entities from different models mutiple objects "ObjectChangeTracker" are getting created.
E.g.
CompanyModel(edmx) - Company(Entity) - ObjectChangeTracker, ObjectState
ProductModel(edmx) - Customer(Entity) - ObjectChangeTracker1, ObjectState1
OrderModel(edmx) - Oder(Entity) - ObjectChangeTracker2, ObjectState2
Is there any way to avoid this?
2) There are few tables which shared across the Models, E.g. Company(Entity) is used in All above mdoels. During compile time it does not thow any error. But run time It gives error saying "Schema specified is not valid. Errors: The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type "Company"".. To resolve this, we renamed the entities with some prefix to make them Unique. Is there any other way we can resolve this without changing the name of the entity in the same assembly?
Thanks in advance and appreciate if anyone has approach for these issues.
Thanks,
Kiran
1) Are you enabling the ChangeTracker always when you grab entities from your data access?
I guess you can't avoid what is created unless you use the POCO Template. It has some more job to be done in some matters but you will have lighter objects. You must then manage the entity state by yourself. I think its good to stay on selftracking but while you use WCF you should change the collection type to FixUpCollection as i can remember to work better with your WCF Service. HINT: Don't forget to disable lazy loading or else you will end up having all the child records you night not want when the entities are serialized.
2) Try and seperate the models in different assemblies, is a better practice and i think you will overcome these problems. I worked this way and its ok.
Hope i helped....
I am building a site that needs to display some product info from a Magento Database, but display it on another page/site outside the Magento intallation. I know the information gets displayed twice, but I would like the site to avoid content duplication and pull that same info from an only source, the Magento product database.
Is this posible? Has anyone done it?
What would be a lot easier to do would be to pull in the entire Magento engine into your external page. This [unlike the rest of Magento] is pretty easy to do.
All you have to do is the following:
// Load Up Magento Core
define('MAGENTO', realpath('/var/www/magento/'));
require_once(MAGENTO . '/app/Mage.php');
$app = Mage::app();
Now you can use any of the Magento objects/classes as if you were inside of Magento and get your attributes
$product = Mage::getModel('catalog/product')->load(1234);
$product->getSku();
$product->getYourCustomAttribute();
etc etc.
Yes, I've done it a few ways. The safest way to do this is using the webservices Magento exposes to query objects programmatically. This will insulate you from database-level changes (such as the flat product catalog, a recent addition).
Failing that (if the performance of the webservices doesn't meet your needs), you can reconstruct the catalog data from the database directly. Use the following tables (assuming you're not using the flat catalog):
eav_entity_type
eav_attribute
catalog_product_entity
catalog_product_entity_int
catalog_product_entity_varchar
catalog_product_entity_text
catalog_product_entity_decimal
catalog_product_entity_datetime
You'll want to read up on EAV models before you attempt this. Bear in mind that this is largely the topic over which people call Magento complicated.
Hope that helps!
Thanks,
Joe