Doctrine Project

[DDC-1496] OrphanRemove does not work when using clear() without initializing the collection before

Fri, 18 Nov 2011 14:45:22 +0000

Collection items (marked with orphanRemoval=true) are not removed from the database correctly if
1. the collection is not initialized
2. we now call ->clear() on it.

I think the problem is that PersistentCollection::clear() iterates through the uninitialized collection which is empty in this case. Thus the scheduleOrphanRemoval() method is never called.

The best example is within the doctrine 2 documentation: http://www.doctrine-project.org/docs/orm/2.0/en/reference/working-with-associations.html#orphan-removal . Calling $this->addresses->clear() raises this bug.

I'm currently helping myself by fixing the situation with accessing the elements of the collection before calling ->clear().

[DDC-1477] GH-177: ProxyFactory was redeclaring methods in some OSs

Wed, 25 Jul 2012 09:55:32 +0000

Pull-Request was automatically synchronized:
https://github.com/doctrine/doctrine2/pull/177

The ProxyFactory was redeclaring methods serialize and unserialize (in my case) on the cache file on some OSs.

Here is the full comment with some screenshots: https://github.com/symfony/symfony/issues/2501

[DDC-1474] Selecting expressions involving the unary minus operator will not work, whereas the EBNF syntax definitions for DQL say they should

Tue, 15 Nov 2011 21:30:50 +0000

DQL queries like:

SELECT - someEntity.someNumericField FROM \SomeEntity someEntity

will result in a syntax error:

[Syntax Error] line 0, col 7: Error: Expected IdentificationVariable | StateFieldPathExpression | AggregateExpression | "(" Subselect ")" | ScalarExpression, got '-''

I think this should work, because the relevant EBNF definitions state the following:

SimpleSelectExpression  ::= ScalarExpression | IdentificationVariable |
                            (AggregateExpression [["AS"] AliasResultVariable])
ScalarExpression       ::= SimpleArithmeticExpression | StringPrimary | DateTimePrimary | StateFieldPathExpression
                           BooleanPrimary | EntityTypeExpression | CaseExpression
SimpleArithmeticExpression ::= ArithmeticTerm {("+" | "-") ArithmeticTerm}*
ArithmeticTerm             ::= ArithmeticFactor {("*" | "/") ArithmeticFactor}*
ArithmeticFactor           ::= [("+" | "-")] ArithmeticPrimary
ArithmeticPrimary          ::= SingleValuedPathExpression | Literal | "(" SimpleArithmeticExpression ")"
                               | FunctionsReturningNumerics | AggregateExpression | FunctionsReturningStrings
                               | FunctionsReturningDatetime | IdentificationVariable | InputParameter | CaseExpression
SingleValuedPathExpression                ::= StateFieldPathExpression | SingleValuedAssociationPathExpression
StateFieldPathExpression                  ::= IdentificationVariable "." StateField | SingleValuedAssociationPathExpression "." StateField

Therefore, the expression "- someEntity.someField" is a legitimate arithmetic factor, which ultimately should be a legitimate scalar expression too, which is a legitimate simple select expression.

Fortunately, this is easy to work around, by simply subtracting from zero, like in:

SELECT 0 - someEntity.someNumericField FROM \SomeEntity someEntity

[DDC-1462] Extra Lazy and slice() on dirty collection

Mon, 31 Oct 2011 20:35:53 +0000

If i slice and the collection is dirty then i have to go to the database.

[DDC-1454] SQL error when requesting state for unknown joined inheritance entity with natural identifier

Thu, 27 Oct 2011 22:59:48 +0000

When having unknown (not cached by UnitOfWork) joined inheritance entity with natural identifier (GENERATOR_TYPE_NONE), method UnitOfWork::getEntityState() fails with SQL error:

Column not found: 1054 Unknown column 't1.file_id' in 'where clause'

Will attach testcase right after creating the issue.

[DDC-1436] Problems with identity map on self-referencing

Fri, 18 Nov 2011 14:02:03 +0000

/**
 * @Orm\Entity
 * @Orm\Table(name="tt_content")
 */
class Page
{
	/**
	 * @Orm\Id
	 * @Orm\GeneratedValue
	 * @Orm\Column(type="integer", name="id")
	 */
	protected $id;

	/**
	 * @Orm\ManyToOne(targetEntity="Page", inversedBy="children")
	 * @Orm\JoinColumn(name="pid", referencedColumnName="id")
	 */
	protected $parent;

	/** @Orm\OneToMany(targetEntity="Page", mappedBy="parent") */
	protected $children;

	/** @Orm\Column(name="page_title") */
	protected $title;
}

$id = 5;

// step 1 
$page = $this
	->getEntityManager('read')
	->createQuery('
		SELECT p, parent
		FROM OloloContentBundle:Page p
			LEFT JOIN p.parent parent
		WHERE p.id = :id
	')
	->setParameter('id', $id)
	->getOneOrNullResult();

// step 2
$page = $this->getEntityManager('read')->find('OloloContentBundle:Page', $id);
var_dump($page->getParent()->getParent()); // expected instance of Page, but got null

When I added one more fetch join for parent then I got Page.

[DDC-1435] Exception thrown when generating SQL from a DQL subselect where the entity has a foreign key as a primary key

Thu, 7 Jun 2012 08:39:52 +0000

If an entity has a foreign key as part of its primary key and you try to query that entity in a subselect clause in DQL, an exception is thrown in ClassMetadataInfo->getQuotedColumnName. The problem seems to be that it's only considering the field mappings rather than both the field and association mappings when it's looking for the correct column name.

Example entities:

Article(id primary key, title, content)
ArticleTag(article_id, tag, primary key (article_id, tag))

Example DQL: select art from Article art where exists (select tag from ArticleTag tag where tag.article = art)

[DDC-1421] SQL Casing in BasicEntityPersister::_getSelectColumnAssociationSQL

Sat, 15 Oct 2011 15:49:28 +0000

SQL Casing is not applied to column alias and method is used twice unnecessarily.

[DDC-1420] doctrine orm:validate-schema failure when using Migrations

Mon, 31 Oct 2011 22:14:43 +0000

I'm using Doctrine 2.1.2 with Migrations 2.0. Doctrine cli tool works
correctly for both schema creation (from annotations) and migrations
but, after using the tool to validate the schema i get the following
error:

[Mapping] OK - The mapping files are correct.
[Database] FAIL - The database schema is not in sync with the current
mapping file.

The failure is caused by the doctrine_migration_versions table that
the migration project has created in the db of my project.

orm:validate-schema fails because the relation is not defined as an
entity in the annotations.

[DDC-1414] UnitOfWork#getCommitOrder() does not add dependencies for all related classes

Sat, 15 Oct 2011 15:49:28 +0000

getCommitOrder() does not add dependencies for all related classes. This causes database-level exceptions in certain cases, as insertion order can be calculated incorrectly, and foreign key constraints fail.

An example case in pseudocode:

A: ManyToOne to B, nullable=true
B: ManyToOne to C, nullable=false
C: no owning relations

a = new A()
em->persist(a)
em->flush()     // does CommitOrderCalculator->addClass(B), but does not add B's dependency to C

c = new C()
b = new B(c)

em->persist(c)
em->persist(b)
em->flush()     // CommitOrderCalculator->hasClass(B) == true, dependencies not added, foreign key constraint fails

Suggested fix against master:

diff --git a/lib/Doctrine/ORM/UnitOfWork.php b/lib/Doctrine/ORM/UnitOfWork.php
index ea516f3..991acac 100644
--- a/lib/Doctrine/ORM/UnitOfWork.php
+++ b/lib/Doctrine/ORM/UnitOfWork.php
@@ -853,6 +853,7 @@ class UnitOfWork implements PropertyChangedListener
                     $targetClass = $this->em->getClassMetadata($assoc['targetEntity']);
                     if ( ! $calc->hasClass($targetClass->name)) {
                         $calc->addClass($targetClass);
+                        $newNodes[] = $targetClass;
                     }
                     $calc->addDependency($targetClass, $class);
                     // If the target class has mapped subclasses,

This $newNodes[] push is done for all new classes in $entityChangeSet (above) and $targetClass->subClasses (below), but not for $targetClass itself. I'm assuming this is a bug, not by design.

[DDC-1411] onCascade property gets wrong value when entities are generated

Sat, 15 Oct 2011 15:54:02 +0000

I'm using this cmd to generate entities "/path/to/php path/to/doctrine orm:generate-entities --generate-annotations="1" ~/some/path".

The CASCADE option for ONDELETE columns is being wrongly generated, the right would be: onDelete="CASCADE" but it is being generated as onDelete=true

[DDC-1410] leftJoin with condition WITH & Object Hydratation problem.

Thu, 7 Jun 2012 23:56:49 +0000

Here an example of a simple QueryBuilder :

$queryBuilder = $entityManager->createQueryBuilder();
$queryBuilder->select ( "player, options" );
$queryBuilder->from ( "Player_Model_Entity_Player", "player");
$queryBuilder->where ("player.idPlayer = 12");
$queryBuilder->leftJoin ("player.options", "options", "WITH", "options.enabled = :enabled");
$queryBuilder->setParameter ("enabled", 1);

OptionA & OptionB & OptionC three entities.
User case :

OptionA.enabled = 1 & OptionB.enabled = 1 & OptionC.enabled = 1 : OK - All options are return.
OptionA.enabled = 1 & OptionB.enabled = 0 & OptionC.enabled = 0 : OK - only optionA is return.
OptionA.enabled = 1 & OptionB.enabled = 0 & OptionC.enabled = 1 : OK - only optionA & optionC is return.
OptionA.enabled = 0 & OptionB.enabled = 1 & OptionC.enabled = 1 : KO - no option return.
OptionA.enabled = 0 & OptionB.enabled = 0 & OptionC.enabled = 0 : OK - no option return.

I have test on OneToMany configuration and I have not problem. The problem only appear with ManyToMany relationships.

The problem seems to be on hydratation. The data return on SQL command seems to be correct.

[DDC-1402] Huge performance leak in SingleTablePersister

Mon, 10 Oct 2011 15:55:50 +0000

This code :

/**
 * @Entity
 * @InheritanceType("SINGLE_TABLE")
 * @DiscriminatorColumn(name="discr", type="string")
 * @DiscriminatorMap({"person" = "Person", "employee" = "Employee"})
 */
class Person
{
    /** @Id @Column(type="integer") */ private $id;
}

/**
 * @Entity
 */
class Employee extends Person
{
    /** @Column(type="integer") */ private $a;
    /** @Column(type="integer") */ private $b;
    /** @Column(type="integer") */ private $c;
    /** @Column(type="integer") */ private $d;
    /** @Column(type="integer") */ private $e;
    /** @Column(type="integer") */ private $f;
    /** @Column(type="integer") */ private $g;
    /** @Column(type="integer") */ private $h;
}

foreach (range(0, 20) as $i) {
    $time = microtime(true);
    foreach (range(1, 100) as $j) {
        $id = ($i * 100) + $j;
        $entityManager->find('Person', $id);
    }
    printf("%4d ==> %f\n", $id, microtime(true) - $time);
}

Will output:

 100 ==> 0.461275
 200 ==> 1.128404
 300 ==> 1.823122
 400 ==> 2.521054
 500 ==> 3.232034
 600 ==> 3.950081
 700 ==> 4.648849
 800 ==> 5.380236
 900 ==> 6.080108
1000 ==> 6.807214
1100 ==> 7.519942
1200 ==> 8.238971
1300 ==> 8.951686
1400 ==> 9.648996
1500 ==> 10.370053
1600 ==> 11.069523
1700 ==> 11.791530
1800 ==> 12.481427
1900 ==> 13.190570
2000 ==> 13.902810
2100 ==> 14.671100

With the first and last SELECT queries as:

SELECT t0.id AS id1, discr, t0.a AS a2, t0.b AS b3, t0.c AS c4, t0.d AS d5, t0.e AS e6, t0.f AS f7, t0.g AS g8, t0.h AS h9 FROM Person t0 WHERE t0.id = 1 AND t0.discr IN ('person', 'employee')

...

SELECT t0.id AS id1, discr, t0.a AS a16794, t0.b AS b16795, t0.c AS c16796, t0.d AS d16797, t0.e AS e16798, t0.f AS f16799, t0.g AS g16800, t0.h AS h16801 FROM Person t0 WHERE t0.id = 2100 AND t0.discr IN ('person', 'employee')

Notes:

Last 100 SELECT queries take more than 14 seconds to execute! (table is empty)
Filed as a bug because a real life scenario caused major performance leak and memory usage when attempting to do 6000 calls to find().

Analysis:

Calls to SingleTablePersister::_getSelectColumnListSQL() do not use BasicEntityPersister::$_selectColumnListSql
This generates a lot of calls to _getSelectColumnSQL() (See last SELECT query with alias counter up to 16800)
This generates a lot of calls to addFieldResult()
And this fills up pretty quickly ResultSetMapping::$declaringClasses
To finally put a huge burden on SimpleObjectHydrator::_prepare() where it iterates on $this->_rsm->declaringClasses and calls getClassMetadata() for each one!
And all that, including _prepare(), is executed for each SELECT, even though none of them find any result (the table is empty).

I fixed my project using the following patch:

diff --git a/doctrine-orm/Doctrine/ORM/Persisters/SingleTablePersister.php b/doctrine-orm/Doctrine/ORM/Persisters/SingleTablePersister.php
index f910a8e..78b27cb 100644
--- a/doctrine-orm/Doctrine/ORM/Persisters/SingleTablePersister.php
+++ b/doctrine-orm/Doctrine/ORM/Persisters/SingleTablePersister.php
@@ -41,6 +41,15 @@ class SingleTablePersister extends AbstractEntityInheritancePersister
     /** {@inheritdoc} */
     protected function _getSelectColumnListSQL()
     {
+        /** @see BasicEntityPersister::_getSelectColumnListSQL() */
+        if ($this->_selectColumnListSql !== null) {
+            return $this->_selectColumnListSql;
+        }
+
+        #####
+        #####
+        #####
+
         $columnList = parent::_getSelectColumnListSQL();
 
         // Append discriminator column
@@ -74,7 +83,13 @@ class SingleTablePersister extends AbstractEntityInheritancePersister
             }
         }
 
-        return $columnList;
+        #####
+        #####
+        #####
+
+        /** @see BasicEntityPersister::_getSelectColumnListSQL() */
+        $this->_selectColumnListSql = $columnList;
+        return $this->_selectColumnListSql;
     }
 
     /** {@inheritdoc} */

I do not know if this patch is safe for everybody.

But, well, you can easily reproduce the problem and analyze the phenomenon using a profiler on the sample code provided.

Thanks for this great piece of software. I hope this will help you find and fix the bug.

[DDC-1400] joining and selecting associated collection, which is using indexBy, to a query is triggering UPDATE queries for each collection element which were joined.

Mon, 2 Jan 2012 13:57:25 +0000

 
/**
 * @Entity
 */
class Article
{

    /**
     * @Id
     * @Column(type="integer")
     */
    protected $id;

    /**
     * @OneToMany(targetEntity="UserState", mappedBy="article", indexBy="userId", fetch="EXTRA_LAZY")
     */
    protected $userStates;

    .......

}

/**
 * @Entity
 */
class User
{

    /**
     * @Id
     * @Column(type="integer")
     */
    protected $id;

    /**
     * @OneToMany(targetEntity="UserState", mappedBy="user", indexBy="articleId", fetch="EXTRA_LAZY")
     */
    protected $userStates;

    .......

}

/**
 * @Entity
 */
class UserState
{

    /**
      * @Id
     *  @ManyToOne(targetEntity="Article", inversedBy="userStates")
     */
    protected $article;

    /**
      * @Id
     *  @ManyToOne(targetEntity="User", inversedBy="userStates")
     */
    protected $user;

    /**
     * @Column(name="user_id", type="integer")
     */
    protected $userId;

    /**
     * @Column(name="article_id", type="integer")
     */
    protected $articleId;

    /**
     * @Column(type="boolean")
     */
    protected $hasLiked;

    .......

}

$q = $em->createQuery("SELECT a, s FROM Article a JOIN a.userStates s WITH s.user = :activeUser");
$q->setParameter('activeUser', $activeUserId);
$q->getResult();

if i $em->flush() now it will execute lots of update queries like:
UPDATE userstate SET article_id = ? WHERE user_id = ? AND article_id = ?

[DDC-1399] Wrong count() value in many-to-many relationship and EXTRA_LAZY

Mon, 31 Oct 2011 20:18:07 +0000

Relation many-to-many, EXTRA_LAZY, $user is owning side. Without EXTRA_LAZY all is ok.

Main problem: counter is increased twice.

$user->getPhotos()->count(); // returns 100 (OK)
$user->addPhoto($photo);
$user->getPhotos()->count(); // returns 101 (OK)
$em->flush();
$user->getPhotos()->count(); // returns 102 (WRONG! Should be 101)

[DDC-1386] getPartialReference() will result in data loss if default values are used

Dependency — Sat, 15 Oct 2011 15:49:29 +0000

If a entity uses default values e.g.

class User {
    private $id;
    private $name = "unnamed";
}

a reference returned from EntityManager::getPartialReference() will automatically result in a scheduled update for this entity (and all fields with default values), because the EM expects the fields of the entity to be empty. This results in resetting all data inside the database to the default values when doing an $em->flush().

Regards Stefan

[DDC-1383] Inheritance superclass object is created after merging entity referencing to discriminated entity

Sat, 15 Oct 2011 17:16:24 +0000

Problem is that after merging the object with a reference to some other entity with inheritance (is one of the superclass's discriminator map), the referenced object has wrong instance (it is Proxy object). It is instance of the superclass not the extended class.

In my test case I have joined inheritance model with only two entities to make things simple as possible.

First is the base entity (I have even marked it as abstract):

/**
 * @Entity
 * @InheritanceType("JOINED")
 * @DiscriminatorColumn(name="discr", type="integer")
 * @DiscriminatorMap({1 = "Entity"})
 */
abstract class AbstractEntity

and one entity which extends from the first one:

/**
 * @Entity
 */
class Entity extends AbstractEntity {
	/**
	 * @ManyToOne(targetEntity="AbstractEntity")
	 * @var AbstractEntity
	 */
	protected $reference;

In this scheme I've got 2 objects, first referencing to the second. They both are inserted in the database with no problems.

$child = new Entity();
$parent = new Entity();
$child->setReference($parent);

After the flush I try merging the child entity into the entity manager, the parent entity reference is not instance of Entity\Entity anymore.

You can see full test case in the archive attached.

[DDC-1382] getIdentifierValues causes an exception on entyties that have only association keys

Sat, 15 Oct 2011 15:49:28 +0000

On entities that have only association keys as primary keys:

Calling BasicEntityPersister::exists() cause the invocation of ClassMetadata::getIdentifierValues() method.
This method returns associated entities as identifier values.
Then BasicEntityPersister::exists() tries to converts these objects to string, instead of searching their primary keys.

Some problems:

getIdentifierValues have not access to external world (only its class metadata and the current entity).
getIdentifierValues is uses in many places of doctrine

(sorry for my bad English)

[DDC-1358] Native Query hydration ignores empty entity doublons

Sun, 16 Oct 2011 09:18:17 +0000

My case is the follwing :

In a range of dates, I want to know if an entity has been defined for each day. So the raw SQL result would looks like :

DATE              ID NAME
--------- ---------- -------------
19-SEP-11          4 [Entity Name]
20-SEP-11          1 [Entity Name]
21-SEP-11          2 [Entity Name]
22-SEP-11          3 [Entity Name]
23-SEP-11       NULL NULL
24-SEP-11       NULL NULL
25-SEP-11       NULL NULL
26-SEP-11       NULL NULL
27-SEP-11          7 [Entity Name]
28-SEP-11          6 [Entity Name]
29-SEP-11          5 [Entity Name]

11 rows selected.

The range calculation forced me to use Native Query, but I stumbled upon a strange behavior : the Result array showed less records than the raw SQL would provide. After some dirty debugging, I found out that during hydration, an array of previously hydrated object keys was stored ObjectHydrator->_identifierMap. The key of null elements (the gap in the SQL result above) is stored too. The problem is that when there is multiple empty elements, hydration only keeps one, and forget the others, thus reducing the overall size of the output result.

I've already come up with a quick n'dirty fix wich suits my current needs, but it would be better if this issue was addressed at a more global level.

Here's the one-liner fix :

Doctrine/ORM/Internal/Hydration/ObjectHydrator.php line 397 was :

                if ( ! isset($this->_identifierMap[$dqlAlias][$id[$dqlAlias]]) ) {

Doctrine/ORM/Internal/Hydration/ObjectHydrator.php line 397 now :

                if ( ! isset($this->_identifierMap[$dqlAlias][$id[$dqlAlias]]) || str_replace( '|', '', $id[$dqlAlias]) == '') {

[DDC-1346] Error when referencing aliased sub-select in where clause

Mon, 31 Oct 2011 20:56:50 +0000

Example:

$qb->addSelect('(SELECT COUNT(tp2) FROM TeamPlayer tp2 WHERE tp2.team = t) AS test');

$qb->andWhere('test > 3');

[Semantical Error] line 0, col 186 near 'test > 3 ORDER': Error: 'test' does not point to a Class.

[DDC-1335] QueryBuilder->form() does not allow the INDEX BY clause

Sun, 25 Sep 2011 22:38:25 +0000

The QueryBuilder does not allow the INDEX BY clause in the form() function, so queris like 'SELECT u FROM User u INDEX BY u.id' are not possible just using the QueryBuilder. There is the option in the join() functions but when a join is not needed, you can only use DQL.

If you find id appropiate i'll work on a patch for the issue.

[DDC-1316] Insert statement for joined subclass presister doesn't type change the id values for subtables

Dependency — Mon, 31 Oct 2011 20:52:06 +0000

Hi there,

I am using "Class Table Inheritance" and this are my entities.

**
 * @Entity
 * @Table (name="Vehicles")
 * @InheritanceType ("JOINED")
 * @DiscriminatorColumn (name="vehicleClass", type="string")
 * @DiscriminatorMap ({"own"="OwnCar", "renta"="RentedCar"})
 */
class Vehicle
{

	/**
	 * @Id
	 * @Column (name="vehicleID", type="integer")
	 */
	protected $vehicleID;

        /**
	 * @Id
         * @Column (name="dateFrom", type="datetime")
         */
	protected $dateFrom;

       .........
}

/**
 * @Table (name="OwnCars")
 * @Entity (repositoryClass="OwnCarRepo")
 */
class OwnCars_Model_Entity_OwnCar extends OwnCars_Model_Entity_Vehicle {

}

As you can see i am using composed id keys. The problem that i get is when building the insert statement the value for the second key which is type datetime is not transformed to date transformed but cast to integer and in the data base i got inserted value of 0000-00-00 00:00:00 instead of the date that i have given. After i did a bit of debugging i found the problem to be in the "Doctrine\ORM\Persisters\JoinedSubclassPersister" on line 163.

foreach ((array) $id as $idVal) {
    $stmt->bindValue($paramIndex++, $idVal);
}

As you can see when you are binding the values for the subtable ids you are not giving the type for the id. So for me to work i did a quick fix:

foreach ((array) $id as $columnNameIdentifier => $idVal) {

    /**
     * Fix untyped join inherited table.
     * All identifiers was typed now.
     */
    $type = \PDO::PARAM_STR;
    if (isset($this->_columnTypes[$columnNameIdentifier])) {
        $type = $this->_columnTypes[$columnNameIdentifier];
    }

    $stmt->bindValue($paramIndex++, $idVal, $type);
}

I hope that you will have time to take a look in to that problem soon as it is important for my project. Otherwise great work so far with the "ORM"

Have a nice day,
Victor

[DDC-1266] doctrine drop sequence twice

Dependency — Mon, 31 Oct 2011 22:04:38 +0000

when "_platform->supportsSequences()", a sequence can be droped twice

patch attached

[DDC-1082] On PostgreSQL "doctrine orm:schema-tool:drop --force" will not delete all tables created by orm:schema-tool:create and still report success

Dependency — Mon, 31 Oct 2011 22:04:47 +0000

doctrine orm:schema-tool:drop --force

will report success even if there are still tables in the schema. The tables remaining are regular tables pertaining to the schema, which was originally created by the doctrine tools, and the tables should have be deleted regularly.

Repeating the command will delete all tables as expected.

I tried this with PostgreSQL 8.4.7 on Debian/Linux 5.0.

Btw, I think there should be another issue priority to assign to bugs like these. I made this a major bug, because in the existing priority system, according to the issue priority definitions, I think this closer to a major bug than to a minor bug because the system gives wrong information to the user, so that the underlying problem manifests in subsequent errors only, and is hard to detect if you believe the console tool's output. Still, it is easy to work around it. I would deem this a "normal" bug. "Major" seems to severe while "minor" seems not severe enough. Do you think it is worthwhile to introduce "normal"? This could help distinguish the real "major" bugs from those just declared as "major" because there was no option to declare them normal, and maybe give you a better focus on the more important bugs.