I'm currently working on a Shopping Cart in which I use a custom Mysql Class to send query to the db.
On this project, I plan to extends this Mysql Class for each Object that I will use : Category, Product, Shopping Cart.
If I create a class like this one:
class Catalog_Categories extends Mysql{}
And then another one like this:
class Catalog_Products extends Mysql{}
Are those classes using the same Mysql Object to connect on DB or are they using 2 separate connections?
I'm a little bit lost.
Thanks!
Carl.
That depends on how your Mysql class is written. If you write it using a Singleton pattern, it will maintain one database instance. You could write it as a Factory pattern and have it generate a new instance for each object that uses it. There are many other patterns and possibilities available so it all just depends on how you want it to work and how you wrote the custom Mysql class.
Assuming that you are creating a database connection in your Mysql class, every object your create of any of the extending classes, will create a new DB connection.
There are several ways to avoid this, for example, you can create one global connection to your database and pass that connection to the constructor of your class so that they all will use that same connection.
Are those classes using the same Mysql Object to connect on DB or are they using 2 separate connections?
We cannot answer this question until we see the complete code.
But extending in this case looks like a bad idea. If you cannot say that class A is a class B - then you should prefer composition over inheritance. This means that Catalog_Products should have a reference to mysql object, but shouldn't extend it.
To get you idea when inheritance is justified is class mysql extends database. In this case you can say "mysql is a database", so extension here looks reasonable as long as database class encapsulates the common logic, and mysql class represents more detailed specifics.
Related
I would like to add a few additional options to the schema $_fieldDefaults array for some documenting purposes.
I tried copying the class and including it in the model in place of the cake schema class but somewhere down the line the constructor is looking for an instance of the cake schema class and not accepting my class.
Does anyone know if it is possable to simply swap out the schema class or would I need to start from the ground up and create a while new db driver to achieve my goals?
If i need to create a driver does anyone have an example or list of requirements needed to do so?
As a side thought,
I am also tossing around the idea of declaring a new public var in the table which holds the schema fields and its options and then just looping through it in the build schema function so that I can always refer to the new variable instead of the schema object however that sounds wrong-ish but simpler than re inventing the wheel.
You might just need to extend the original class in your new class.
<?php
namespace \your\new\class\namespace
use original\schema\class\schemaClassName
class YourNewClass extends schemaClassName {
//new code here
}
I am trying to create simple database abstraction layer. I read a lot of articles about Active Record and Table Data Gateway and right now I am very confused.
I think that I understand some theory (small) about them but not how exactly to implement them. I have choosed to implement Data Table Gateway. I will try to explain what I did and if you give me some advices I will be glad. I am not sure why (for example in ZF2) every time I have to use Table Data Gateway like DI in the models.
In my case my AbstractModel just get DbAdapter in the constrictor by IoC container but I am not sure that this is ok.
Ok I will describe my situation.
I have following classes:
DbAdapter -> it creates db connection (using PDO)
IoC (Inversion of Control Container)
AbstractModel -> in constructor I get DbAdapter using IoC. This means that it hold only one instance of DbAdapter. In this class I also have CRUD methods.
Another classes represent the tables in db. For example class User extends AbstractModel and has method getTable which return the name of the table. Another sql queries will be in this classes which represent the tables. These classes have access to DbAdapter.
Is it ok this scheme and how can I improve it?
I'm looking in to using NotORM for a project (no code has been written yet).
I get that NotORM can make an object based on MySQL tables. What I don't quite understand is how I use it if I have an existing class in place. Should I inject NotORM in to the class? But then how do I use it to load/save from the db?
I guess the main problem I am trying to understand is if I have a class that I save to the db over multiple tables (let's call it MyClass), I understand why an ORM is a good idea, as the class may be stored over multiple tables in the db, but what if MyClass has some methods that do other stuff (for example maybe it talks to an external api elsewhere)? Just loading straight from the db using NotORM is not going to make the same 'MyClass' - from what I understand it will only have the data from the db.
i'm new to php and codeigniter but i have experience with pylons and sqlalchemy.
there you define model classes and then you use command something like "paster setup-app development.ini" and (paster?) creates tables for you and you dont have to write any sql code...
i was trying this with codeigniter and datamapper but so far i'm not sure if it is possible. so here i am asking you if it is possible?
i am very confused because in "models/" you can put your own classes (like in sqlalchemy). in these classes you define every attribute, relationship and other stuff. so why would you need to write the same thing 2 times? (1st in this class 2nd in sql script)
That is not possible, Datamapper implements the Active Record pattern which expects the tables to be there.
There is no need to define any attributes in a Datamapper model, it will be fetched from the associated table (and cached).
The Situation:
I am using a db class as a wrapper (dbwrapper) to open and close db connections via PHP PDO
I have 3 separate classes which extend this db wrapper
I instantiate 3 objects from said classes and in the course of their existence they each make db queries
MySQL used in this case.
When the methods of the 3 classes require db access they each create PDO objects internally, making use of the dbwrapper which they extended. Each object is storing its PDO object in a member/field for reference by itself.
The Question: My question is this... is each object creating a separate connection to the database, making 3 in total? Is each client of Apache creating only one connection to the database or is each object using the db in a php application creating a connection. (sounds inefficient!)
The Reason: I would like to understand how these connections are handled.
I am trying to decide if it would be better to have each class extend the dbwrapper or if it would be better to initialize the dbwrapper without making an automatic connection the db, handle that when its needed. Instead I would pass the dbwrapper to each objects constructor as they are initialized... letting them use that reference. If multiple db connections are happening then I think this would be the best way to minimize overhead while overcoming issues of object's scope and access.
Thanks in advance!
is each object creating a separate connection to the database, making 3 in total?
Maybe. I don't know, but here's how to find out. While your script is running, connect to MySQL via your client of choice (like the command line) and issue the command SHOW PROCESSLIST; You'll get a list of active connections.
You might need to insert a sleep in your script to keep it alive long enough for you to run the process list command when you've instantiated and are working on all three objects.
You'll see either one connection or three. Then you'll have your answer.
(The answer will vary depending on the underlying driver. Some drivers will reuse the connection if the DSN is identical.)
Instead I would pass the dbwrapper to each objects constructor as they are initialized... letting them use that reference
This is the common practice. Database handles are prime candidates for the Singleton pattern as well.