I often get to the point in building a new Magento site where 301 rewrites need creating for all the items on the old site. Is there a way of importing them directly?
Programmatically via a urlCreate() type Magento function would be fine as then I could just cycle through a csv.
Generally it's a good idea to stick with Magento's ORM for interacting with entity data, as there may be both business logic and storage logic which is baked into the entity ORM stack (this is notoriously true for EAV entities). But, depending on the number of records to be entered, a direct-to-db approach should be fine, especially if it's a one-off import. This is because URL rewrites are flat entities stored in the core_url_rewrite table (link), and the table itself has the necessary storage logic as part of its structure (mainly, unique request_path + store_id and an FK for core_store table). In other words, manipulating this data outside of the ORM tier is okay because the logic is part of the table definition itself.
Beyond this information, it's possible to load up a core/url_rewrite collection, create core/url_rewrite instances from the CSV and add them, and then call save() on the collection, but note that each item is saved individually. It might do to refer to the convert adapters for catalog entities and for customers, which is how dataflow works.
Related
I want to create a membership based site in Umbraco 7, following the umbraco.tv videos and reading through the docs have got me quite far.
My members will have custom properties, firstname, lastname, favourite colours, hats owned etc. I have been adding each of these as custom properties and then assigning them to the tab I want. This works fine and I can then access them from code using:
Members.GetCurrentMember().GetProperty("lastname").Value.ToString();
When I looked in my database I noticed that each of these custom properties is a row in the cmsPropertyData table, linked to the cmsMember table by the nodeId column. Is there a way I can set all of this information to store in it's own table?
Ideally, I want each Member to have a one to many relationship with favourite colours, as well as one to many relationships with other tables; each member might have 100 hats for example. What is the best way for me to set this up? Shall I create custom tables in my Umbraco database for HatsOwned and FavouriteColours, then assign each Member a unique ID so I can set my foreign keys up correctly? That way I would only need to store the Members Unique Id in the cmsPropertyTable. Is there a better way to let Umbraco deal with it? Would I have difficulty retrieving Members using either the Umbraco orm, or EF?
Any help or pointers greatly appreciated!
I would store all data in the PROFILE of the member, in the umbraco membership. E.g. timezone, hair color, ... This makes sense for other developers to find back the data.
For all other data, you have a few options:
Relationships
If you want to link nodes to members, or nodes to nodes, or... Relations link 2 umbraco entities and can be one way or two way. If you have a color node, you can link all members to this node. Just create a "favoriteColor" relationship on the developer section, linking up nodes to members. Do some programming and you are done. Don't forget that a relation is a database record linking 2 umbraco entities. So think of some caching if you use this in your front end to take off some database load. Read more on the Relationship Api in the umbraco documentation.
Content
It's pretty easy to create new nodes using code to store e.g. comments on an article. Because you are republishing the xml cache every time you create (and publish) a node, don't use content nodes for stroring your data if you have a lot of updates.
External data
It is perfectly legit to store data outside of umbraco. Just create your own tables (or content to any service you created). You could use every ORM you want to, but I would recommend PetaPoco. The reason is obvious. Umbraco uses it also. And it will make you a better Umbraco developer. There is a detailed post on stackoverflow on how to work with external data in umbraco.
I am currently working on a project where we are rewriting software that was originally written in Visual DataFlex and we are changing it to use SQL and rewriting it into a C# client program and a C#/ASP.Net website. The current database for this is really horrible and has just had columns added to table or pipe(|) characters stuck between the cell values when they needed to add new fields. So we have things like a person table with over 200 columns because stuff like 6 lots of (addressline1, addressline2, town, city, country, postcode) columns for storing different addresses (home/postal/accountPostal/ect...).
What we would like to do is restructure the database, but we also need to keep using the current structure so that the original software can still work as well. What I would like to know is would it be possible using Linq to write a DataContext Object Model Class that could sort of interpret the data base structures so that we could continue to use the current database structure, but to the code it could look like we where using the new structure, and then once different modules of the software are rewritten we could change the object model to use the correct data structure???
First of all, since you mention the DataContext I think you're looking at Linq to SQL? I would advice to use the Entity Framework. The Entity Framework has more advanced modeling capabilities that you can use in a scenario as yours. It has the ability to construct for example a type from multiple tables, use inheritance or complex types.
The Entity Framework creates a model for you that consists of three parts.
SSDL which stores how your database looks.
CSDL which stores your model (your objects and the relationships between them)
MSL which tells the Entity Framework how to map from your objects to the database structure.
Using this you can have a legacy database and map this to a Domain Model that's more suited to your needs.
The Entity Framework has the ability to create a starting model from your database (where all tables, columns and associations are mapped) en then you can begin restructuring this model.
These classes are generated as partial so you could extend them by for exampling splitting the database piped fields into separate properties.
Have you also thought about using Views? If possible you could at views to your database that give you a nicer dataschema to work with and then base your model on the views in combination with stored procedures.
Hope this gives you any ideas.
After building some frontend stuff, I'm now exploring the internals of the admin side of Magento. I read Alan Storm's article on creating a simple model (as opposed to an EAV model, something which I am not yet ready for).
My main goal is to create a module that enables the user to upload and manage media to the Magento installation, so that it can be used in some templates I defined in the frontend. So I would create a model to keep track of the relations between certain media (pictures) and certain categories, pages, you name it. Just for the record: I don't like EAV models, they scare me, so unless it's absolutely necessary, don't push the conversation that way. Thank you :)
I've also skimmed through this article.
It's about backend models, and my question is about that:
What IS a backend model?
Is it a model that's used only in the backend (admin)? I wouldn't know what that would be good for. If someone could tell me something about it, or give me a hint on what to read to know more about it, it'd be great.
The reason I'm telling what goal I want to reach is so that someone can tell me if these "backend models" are significant to what I want.
Thanks!
Don't worry about EAV, don't worry about "backend models". You'll need some in the trenches programming experience before you can fully understand their significance. You can get a lot done with the plain-jane Magento model classes and SQL queries.
The light version: Backend models have nothing to do with the frontend-cart/backend-admin application split. A "backend model" handles loading, storing, and persisting information into a datastore (the database). A "frontend model" is PHP code that handles rendering a user interface element to display the attribute in the web browser. The terms are used in several different systems in Magento, including EAV and the System Configuration section.
The article you linked to is talking abou EAV backend models. Again, the light version: Each data property of an EAV model is, itself, an object. For example, in a simpler system you'd store the product's name as the string 'Bicycle'. In Magento you assign a product attribute object to the parent EAV model for name. This way, the code for saving "name" to the database can be kept separate from the other saving code.
Long story short, It's overkill for what you're after.
In Magento backend attribute models is used to prepare data before placing it in the database. This preparation is done by beforeSave method. A good exampe is Mage_Eav_Model_Entity_Attribute_Backend_Datetime
I am wondering how the models in code ignitor are suposed to be used.
Lets say I have a couple of tables in menu items database, and I want to query information for each table in different controllers. Do I make different model classes for each of the tables and layout the functions within them?
Thanks!
Models should contain all the functionality for retrieving and inserting data into your database. A controller will load a model:
$this->load->model('model_name');
The controller then fetches any data needed by the view through the abstract functions defined in your model.
It would be best to create a different model for each table although its is not essential.
You should read up about the MVC design pattern, it is used by codeigniter and many other frameworks because it is efficient and allows code reuse. More info about models can be found in the Codeigniter docs:
http://codeigniter.com/user_guide/general/models.html
CodeIgniter is flexible, and leaves this decision up to you. The user's guide does not say one way or the other how you should organize your code.
That said, to keep your code clean and easy to maintain I would recommend an approach where you try to limit each model to dealing with an individual table, or at least a single database entity. You certainly want to avoid having a single model to handle all of your database tables.
For my taste, CodeIgniter is too flexible here - I'd rather call it vague. A CI "model" has no spec, no interface, it can be things as different as:
An entity domain object, where each instance represents basically a record of a table. Sometimes it's an "anemic" domain object, each property maps directly to a DB column, little behaviour and little or no understanding of objects relationships and "graphs" (say, foreign keys in the DB are just integer ids in PHP). Or it can also be a "rich (or true) domain object", with all the business intelligence, and also knows about relations: say instead of $person->getAccountId() (returns int) we have $person->getAccount(); perhaps also knows how to persist itself (and perhaps also the full graph or related object - perhaps some notion of "dirtiness").
A service object, related to objects persistence and/or general DB querying: be a DataMapper, a DAO, etc. In this case we have typically one single instance (singleton) of the object (little or no state), typically one per DB table or per domain class.
When you read, in CI docs or forums, about , say, the Person model you can never know what kind of patter we are dealing with. Worse: frequently it's a ungly mix of those fundamentally different patterns.
This informality/vagueness is not specific to CI, rather to PHP frameworks, in my experience.
I have a doctrine data model with a table Person, however my Symfony application is only part of a bigger web application, which is build in Joomla. For a module, I need to add a number of fields from a view, which spans 8 tables with the person table. The view is already established for the Joomla part of things.
Short of creating a schema for all the tables involved, is there a way to arbitrarily join the view in my tableMethod? As another shortcut I am thinking of creating a minimal schema.yml table to just represent the field of the view that I need.
another solution would be to use native sql with doctrine