[fw-general] Re: Pdo_Mssql and column defaults
Oddly, I can do the following and get the info.
Create temporary table to hold output of sp_columns:
create table #client_columns(
TABLE_QUALIFIERsysname
,TABLE_OWNERsysname
,TABLE_NAMEsysname
,COLUMN_NAMEsysname
,DATA_TYPEsmallint
,[TYPE_NAME]sysname
,[PRECISION]int
,[LENGTH]int
,SCALEsmallint
,RADIXsmallint
,NULLABLEsmallint
,REMARKSvarchar(254)
,COLUMN_DEFnvarchar(4000)
,SQL_DATA_TYPEsmallint
,SQL_DATETIME_SUBsmallint
,CHAR_OCTET_LENGTHint
,ORDINAL_POSITIONint
,IS_NULLABLEvarchar(254)
,SS_DATA_TYPEtinyint
)
Insert ouput into temp table:
insert into #client_columns
exec sp_columns @table_name = 'clients'
Then this works:
$result = mssql_query( SELECT * FROM client_columns, $db);
while( $row = mssql_fetch_assoc( $result)) {
print_r( $row);
}
This never works:
$result = mssql_query( exec sp_columns @table_name = 'clients', $db);
while( $row = mssql_fetch_assoc( $result)) {
print_r( $row);
}
Thanks,
Eric Humphrey MCDBA, MCSA
Senior Developer
Bowman Systems, LLC
333 Texas Street, Suite 300
Shreveport, LA 71101
Phone: (318) 213-8780 x128
Fax : (318) 213-8784
Website: http://www.bowmansystems.com
IMPORTANT WARNING: This message is intended for the use of the person or
entity to which it is addressed and may contain information that is privileged
and confidential, the disclosure of which is governed by applicable law. If
the reader of this message is not the intended recipient, or the employee or
agent responsible to deliver it to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this information is
strictly prohibited. If you have received this message in error, please notify
the sender immediately and arrange for the return or destruction of these
documents.
Eric Humphrey wrote:
Trying to get column defaults using $db-describeTable() and
$array['COLUMN_DEF'] always comes back empty. Using php 5.2.5, ZF
1.0.3, SQL 2005. Everything looks OK in
library/Zend/Db/Adapter/Pdo/Mssql.php at quick glance. Added an
error_log statement to output $row at line 245 and it always shows
empty there as well. Everything else works, so it seems.
Re: [fw-general] Reducing the number of loaded exception files
I would suggest to incorporate a method that serves as a central location to
instantiate exception objects - a *consistent *object-instantiation system,
if you will. This method could go inside a class that is always
required/loaded so we don't have to include another file just for this
purpose. Zend_Loader, maybe? This approach allows us to add more
processing/error-handling logic to the method in future that ripples across
the framework:
//
static function getException( $class, $message = 'ERROR', $code = 0, ... )
//
{
self::loadClass( $class );
//
// Or straight require_once for performance, but then format the
class-name to instantiate...
// require_once( $class );
//
return new $class( $message, $code, ... );
}
Then, from within the code where an exception needs to be thrown, this
becomes just a simple *one-liner*,* *instead of spilling require_once/etc
lines of code all over the framework:
throw Zend_Loader::getException( class, message, code, ... );
2. On another note, how about *other *class-files that get included
superfluously? I'm quite sure there are an awful lot of files included in
the framework's classes without ever being used. ViewRenderer.php is just an
example. If we really want to reduce the number of included files to improve
performance, we need to work on these ones, too. Bottom line - include files
only on a *need-to-use *basis and *just-in-time*! I, for one, don't want any
files loaded that I don't want to use in my application - its just an
over-head.
my2c
On 12/13/07, Shahar Evron [EMAIL PROTECTED] wrote:
A while back ago there was an attempt to eliminate the loading of unused
Exception files / classes by different ZF components. I don't know what
happened with that discussion, but I think we should do something about
it.
I've made some profiling of relatively simple ZF-based app (doesn't load
too many components - mostly the MVC, DB, Config, Registry etc. stuff)
and I've found some 10 calls to require_once to load an Exception class
without having a single exception thrown (that I know of - unless some
ZF code threw an exception and some other ZF component caught it).
10 redundant include files have quite an impact on performance,
especially in places where you have no opcode cache installed.
A while back ago I changed Zend_Http_Client to require_once it's
exception classes only when about to throw an exception, something like:
?php
if ($error_happened) {
require_once 'Zend/Http/Client/Exception.php';
throw new Zend_Http_Client_Exception('Good news, everyone!');
}
?
Now this might seem a bit cumbersome - but when considering the fact
that it's 1 line of code that never gets executed vs. always loading at
least one aditional file (not to mention cases where you load
Zend/Http/Client/Adapter/Exception.php which loads
Zend/Http/Client/Exception.php which loads Zend/Http/Exception.php which
loads Zend/Exception.php - you get the point) I think it's worth it.
If nobody has a nicer solution to this overweight problem, I suggest all
component maintainers will start doing the same (this is not my idea and
I know some already do so).
If you want, I can try to come up with a list of places that need to be
fixed.
Better suggestions are most welcome!
Thanks,
Shahar.
--
Shahar.
[fw-general] Re: Pdo_Mssql and column defaults
Not a php bug. User must be granted *VIEW DEFINITION* permission on
database.
Thanks,
Eric Humphrey MCDBA, MCSA
Senior Developer
Bowman Systems, LLC
333 Texas Street, Suite 300
Shreveport, LA 71101
Website: http://www.bowmansystems.com
IMPORTANT WARNING: This message is intended for the use of the person or
entity to which it is addressed and may contain information that is privileged
and confidential, the disclosure of which is governed by applicable law. If
the reader of this message is not the intended recipient, or the employee or
agent responsible to deliver it to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this information is
strictly prohibited. If you have received this message in error, please notify
the sender immediately and arrange for the return or destruction of these
documents.
Eric Humphrey wrote:
Oddly, I can do the following and get the info.
Create temporary table to hold output of sp_columns:
create table #client_columns(
TABLE_QUALIFIERsysname
,TABLE_OWNERsysname
,TABLE_NAMEsysname
,COLUMN_NAMEsysname
,DATA_TYPEsmallint
,[TYPE_NAME]sysname
,[PRECISION]int
,[LENGTH]int
,SCALEsmallint
,RADIXsmallint
,NULLABLEsmallint
,REMARKSvarchar(254)
,COLUMN_DEFnvarchar(4000)
,SQL_DATA_TYPEsmallint
,SQL_DATETIME_SUBsmallint
,CHAR_OCTET_LENGTHint
,ORDINAL_POSITIONint
,IS_NULLABLEvarchar(254)
,SS_DATA_TYPEtinyint
)
Insert ouput into temp table:
insert into #client_columns
exec sp_columns @table_name = 'clients'
Then this works:
$result = mssql_query( SELECT * FROM client_columns, $db);
while( $row = mssql_fetch_assoc( $result)) {
print_r( $row);
}
This never works:
$result = mssql_query( exec sp_columns @table_name = 'clients', $db);
while( $row = mssql_fetch_assoc( $result)) {
print_r( $row);
}
Thanks,
Eric Humphrey MCDBA, MCSA
Senior Developer
Bowman Systems, LLC
333 Texas Street, Suite 300
Shreveport, LA 71101
Website: http://www.bowmansystems.com
IMPORTANT WARNING: This message is intended for the use of the person
or entity to which it is addressed and may contain information that is
privileged and confidential, the disclosure of which is governed by
applicable law. If the reader of this message is not the intended
recipient, or the employee or agent responsible to deliver it to the
intended recipient, you are hereby notified that any dissemination,
distribution or copying of this information is strictly prohibited.
If you have received this message in error, please notify the sender
immediately and arrange for the return or destruction of these documents.
Eric Humphrey wrote:
Trying to get column defaults using $db-describeTable() and
$array['COLUMN_DEF'] always comes back empty. Using php 5.2.5, ZF
1.0.3, SQL 2005. Everything looks OK in
library/Zend/Db/Adapter/Pdo/Mssql.php at quick glance. Added an
error_log statement to output $row at line 245 and it always shows
empty there as well. Everything else works, so it seems.
Re: [fw-general] Reducing the number of loaded exception files
I'm just going off memory right now, but I think stack traces for
exception objects are wound up from the point which they are created,
not the point which they are thrown from. So this would mean that when
you look at the trace from the exception, it originates from the
getException method, rather than the place you are wanting to throw it from.
-ralph
Shekar C Reddy wrote:
I would suggest to incorporate a method that serves as a central
location to instantiate exception objects - a *consistent
*object-instantiation system, if you will. This method could go inside
a class that is always required/loaded so we don't have to include
another file just for this purpose. Zend_Loader, maybe? This approach
allows us to add more processing/error-handling logic to the method in
future that ripples across the framework:
//
static function getException( $class, $message = 'ERROR', $code = 0, ... )
//
{
self::loadClass( $class );
//
// Or straight require_once for performance, but then format the
class-name to instantiate...
// require_once( $class );
//
return new $class( $message, $code, ... );
Re: [fw-general] Reducing the number of loaded exception files
It's at the throw, not at instantiation.
On Dec 14, 2007 12:14 PM, Ralph Schindler [EMAIL PROTECTED] wrote:
I'm just going off memory right now, but I think stack traces for
exception objects are wound up from the point which they are created,
not the point which they are thrown from. So this would mean that when
you look at the trace from the exception, it originates from the
getException method, rather than the place you are wanting to throw it from.
-ralph
Shekar C Reddy wrote:
I would suggest to incorporate a method that serves as a central
location to instantiate exception objects - a *consistent
*object-instantiation system, if you will. This method could go inside
a class that is always required/loaded so we don't have to include
another file just for this purpose. Zend_Loader, maybe? This approach
allows us to add more processing/error-handling logic to the method in
future that ripples across the framework:
//
static function getException( $class, $message = 'ERROR', $code = 0, ... )
//
{
self::loadClass( $class );
//
// Or straight require_once for performance, but then format the
class-name to instantiate...
// require_once( $class );
//
return new $class( $message, $code, ... );
Re: [fw-general] Reducing the number of loaded exception files
Why not just implement the __autoload function and handle the require_once
for the Exception class there?
On Dec 14, 2007 4:19 PM, Jordan Moore [EMAIL PROTECTED] wrote:
It's at the throw, not at instantiation.
On Dec 14, 2007 12:14 PM, Ralph Schindler [EMAIL PROTECTED] wrote:
I'm just going off memory right now, but I think stack traces for
exception objects are wound up from the point which they are created,
not the point which they are thrown from. So this would mean that when
you look at the trace from the exception, it originates from the
getException method, rather than the place you are wanting to throw it
from.
-ralph
Shekar C Reddy wrote:
I would suggest to incorporate a method that serves as a central
location to instantiate exception objects - a *consistent
*object-instantiation system, if you will. This method could go inside
a class that is always required/loaded so we don't have to include
another file just for this purpose. Zend_Loader, maybe? This approach
allows us to add more processing/error-handling logic to the method in
future that ripples across the framework:
//
static function getException( $class, $message = 'ERROR', $code = 0,
... )
//
{
self::loadClass( $class );
//
// Or straight require_once for performance, but then format the
class-name to instantiate...
// require_once( $class );
//
return new $class( $message, $code, ... );
--
Craig Slusher
[EMAIL PROTECTED]
[fw-general] Re[fw-general] move trailing parameters when using Redirector Helper?
Hi guys,
having this route definition:
$oRoute = new Zend_Controller_Router_Route
(
'features/:controller/:action/*',
array('action' = 'list')
);
$oRouter-addRoute('features', $oRoute);
I tried couple of things, however, I can't get rid of the 'paramaters part'
of the URL after redirection, so result after redirection looks like
features/types/list/id/X/.
After successful validation of a form in one of controllers
(features/types/edit/id/X), I'd like to be redirected ideally back to
features/types/ (or to features/types/list/ - list is default action - when
the previous is impossible).
Any ideas how to get rid of these parameters, pls? And Is there a way how
skip setting the initial action (list) when redirecting? OR is something
wrong with the route? Sorry if it's a newbie question, I'm quite new to ZF.
Thanks for help
--
View this message in context:
http://www.nabble.com/Remove-trailing-parameters-when-using-Redirector-Helper--tp14339813s16154p14339813.html
Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] Re: Re[fw-general] move trailing parameters when using Redirector Helper?
Not sure if this is what you mean, but you can set the third parameter,
$reset, to true:
$this-_helper-Redirector-gotoRoute(array(), 'features', true);
That will build the route from scratch so to speak.
Nogyara wrote:
Hi guys,
having this route definition:
$oRoute = new Zend_Controller_Router_Route
(
'features/:controller/:action/*',
array('action' = 'list')
);
$oRouter-addRoute('features', $oRoute);
I tried couple of things, however, I can't get rid of the 'paramaters
part' of the URL after redirection, so result after redirection looks like
features/types/list/id/X/.
After successful validation of a form in one of controllers
(features/types/edit/id/X), I'd like to be redirected ideally back to
features/types/ (or to features/types/list/ - list is default action -
when the previous is impossible).
Any ideas how to get rid of these parameters, pls? And Is there a way how
skip setting the initial action (list) when redirecting? OR is something
wrong with the route? Sorry if it's a newbie question, I'm quite new to
ZF.
Thanks for help
--
View this message in context:
http://www.nabble.com/Remove-trailing-parameters-when-using-Redirector-Helper--tp14339813s16154p14339823.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Reducing the number of loaded exception files
I wish that were the case, but not so much.
We actually did have this functionality, and removed it for various
reasons, you can look back at this post:
http://www.nabble.com/Re-3A-Do-we-really-need-Zend-3A-3Aexception-28-29--to7929347s16154.html#a7929347
for conclusions.
As for the code behind stacks, hope this helps:
C:\Documents and Settings\rschindler\My Documents\testscat etest.php
?php
class E_Factory
{
static public function getException()
{
$e = new Exception();
return $e;
}
}
class E_Thrower
{
public function sayEFactory()
{
throw E_Factory::getException();
}
public function sayE()
{
throw new Exception();
}
}
$c = new E_Thrower();
echo 'From factory - getLine() says: ';
try {
$c-sayEFactory();
} catch (Exception $e) {
echo $e-getLine();
}
echo PHP_EOL . 'From direct getLine() says: ';
try {
$c-sayE();
} catch (Exception $e) {
$t = $e-getTrace();
echo $e-getLine();
}
C:\Documents and Settings\rschindler\My Documents\testsphp etest.php
From factory - getLine() says: 7
From direct getLine() says: 20
This was also actually implemented at one point, then we took it out for
that exact reason.
Jordan Moore wrote:
It's at the throw, not at instantiation.
On Dec 14, 2007 12:14 PM, Ralph Schindler [EMAIL PROTECTED] wrote:
I'm just going off memory right now, but I think stack traces for
exception objects are wound up from the point which they are created,
not the point which they are thrown from. So this would mean that when
you look at the trace from the exception, it originates from the
getException method, rather than the place you are wanting to throw it from.
-ralph
Shekar C Reddy wrote:
I would suggest to incorporate a method that serves as a central
location to instantiate exception objects - a *consistent
*object-instantiation system, if you will. This method could go inside
a class that is always required/loaded so we don't have to include
another file just for this purpose. Zend_Loader, maybe? This approach
allows us to add more processing/error-handling logic to the method in
future that ripples across the framework:
//
static function getException( $class, $message = 'ERROR', $code = 0, ... )
//
{
self::loadClass( $class );
//
// Or straight require_once for performance, but then format the
class-name to instantiate...
// require_once( $class );
//
return new $class( $message, $code, ... );
[fw-general] Re: [fw-core] Re: [fw-general] Reducing the number of loaded exception files
Matthew,
Zend_Controller_Front.php has the following lines of code on the top instead
of conditionally requiring them in dispatch():
/** Zend_Controller_Action_Helper_ViewRenderer */
require_once 'Zend/Controller/Action/Helper/ViewRenderer.php';
/** Zend_Controller_Plugin_ErrorHandler */
require_once 'Zend/Controller/Plugin/ErrorHandler.php';
For those who don't use ViewRenderer and ErrorHandler, these files still get
included on each page-load unless they are moved into dispatch() to require
them conditionally:
http://framework.zend.com/issues/browse/ZF-2313
Regards,
On 12/14/07, Matthew Weier O'Phinney [EMAIL PROTECTED] wrote:
-- Shekar C Reddy [EMAIL PROTECTED] wrote
(on Friday, 14 December 2007, 12:50 PM -0600):
I would suggest to incorporate a method that serves as a central
location to
instantiate exception objects - a consistent object-instantiation
system, if
you will. This method could go inside a class that is always
required/loaded so
we don't have to include another file just for this purpose.
Zend_Loader,
maybe? This approach allows us to add more processing/error-handling
logic to
the method in future that ripples across the framework:
//
static function getException( $class, $message = 'ERROR', $code = 0, ...
)
//
{
self::loadClass( $class );
//
// Or straight require_once for performance, but then format the
class-name to instantiate...
// require_once( $class );
//
return new $class( $message, $code, ... );
}
///
/
Then, from within the code where an exception needs to be thrown, this
becomes
just a simple one-liner, instead of spilling require_once/etc lines of
code all
over the framework:
throw Zend_Loader::getException( class, message, code, ... );
There are *no* classes right now that get loaded by every other class;
doing so introduces unwanted coupling.
2. On another note, how about other class-files that get included
superfluously? I'm quite sure there are an awful lot of files included
in the framework's classes without ever being used. ViewRenderer.php
is just an example.
For what it's worth, the ViewRenderer is loaded during dispatch() only
if the user has not set the 'noViewRenderer' flag; same with the
ErrorHandler plugin. Users complained about them being loaded, and we
listened. :-)
If we really want to reduce the number of included files to improve
performance, we need to work on these ones, too. Bottom line - include
files only on a need-to-use basis and just-in-time! I, for one, don't
want any files loaded that I don't want to use in my application - its
just an over-head.
Perhaps you could go and create a list that shows these? I think in most
cases, we're not doing includes unless needed... with the exception of
exception classes, but we cannot know unless somebody produces an audit.
On 12/13/07, Shahar Evron [EMAIL PROTECTED] wrote:
A while back ago there was an attempt to eliminate the loading of
unused
Exception files / classes by different ZF components. I don't know
what
happened with that discussion, but I think we should do something
about
it.
I've made some profiling of relatively simple ZF-based app (doesn't
load
too many components - mostly the MVC, DB, Config, Registry etc.
stuff)
and I've found some 10 calls to require_once to load an Exception
class
without having a single exception thrown (that I know of - unless
some
ZF code threw an exception and some other ZF component caught it).
10 redundant include files have quite an impact on performance,
especially in places where you have no opcode cache installed.
A while back ago I changed Zend_Http_Client to require_once it's
exception classes only when about to throw an exception, something
like:
?php
if ($error_happened) {
require_once 'Zend/Http/Client/Exception.php';
throw new Zend_Http_Client_Exception('Good news, everyone!');
}
?
Now this might seem a bit cumbersome - but when considering the fact
that it's 1 line of code that never gets executed vs. always loading
at
least one aditional file (not to mention cases where you load
Zend/Http/Client/Adapter/Exception.php which loads
Zend/Http/Client/Exception.php which loads Zend/Http/Exception.php
which
loads Zend/Exception.php - you get the point) I think it's worth it.
If nobody has a nicer solution to this overweight problem, I suggest
all
component maintainers will start doing the same (this is not my idea
and
I know some already do so).
If you want, I can try to come up with a list of places
