My after hours project

I'll have a look once it's up again, but the idea sounds promising.

Naturally the reviews will be skewed, but the target market is generally smart enough to realize this. This would be even more apparent if most of the reviews are bad as this will push a dev to choose the best of the worst.
 
Clicked "My Reviews" and got this:

Column names in each table must be unique. Column name 'CompanyClaimID' in table 'dbo.Companies' is specified more than once.
 
sp4ceman said:
yeah the entity framework migrations are corked, they keep trying to rerun and readd a column that's already there.. don't have db access right now so can't fix it
Click to expand...

Theres your problem, entityframework :sick:
 
here we go... the reason i went with entity framework is their new version 6 isn't that bad and their code first has come a long way.

plus it's built in and is sort of the standard for dotnet sites. it integrates nicely with new relic, glimpse, the stackexchange
mini profiler and all the rest.

i have used other orms in my projects but it's always felt like fighting the system.

the retarded migration bug we are currently experiencing is the first real negative thing so far.
 
semaphore said:
Theres your problem, entityframework :sick:
Click to expand...
I use EF6 with code migrations daily with zero issues. Once you get migrations figured out it becomes a total pleasure to use.
Current project uses migrations across three contexts and keeps 3 dev DB's, staging and production DB's perfectly in sync with our domain models.

How is the posters issue EF's problem? More like configuration issues. Most important - don't use auto migrations. You lose control of the schema changes and it's dangerous.
 
sp4ceman said:
here we go... the reason i went with entity framework is their new version 6 isn't that bad and their code first has come a long way.

plus it's built in and is sort of the standard for dotnet sites. it integrates nicely with new relic, glimpse, the stackexchange
mini profiler and all the rest.

i have used other orms in my projects but it's always felt like fighting the system.

the retarded migration bug we are currently experiencing is the first real negative thing so far.
Click to expand...

Yep, it is the first negative thing, apart from their entire framework.

We do with high volume transactions, entityframework was extremely poor candidate for us.
 
semaphore said:
Yep, it is the first negative thing, apart from their entire framework.

We do with high volume transactions, entityframework was extremely poor candidate for us.
Click to expand...

Shouldn't be using any ORM then surely? I have used quite a few of the tools on the market, and find high volume stuff should be kept as native to the DB as possible if performance is key.
 
Mike Smit said:
Shouldn't be using any ORM then surely? I have used quite a few of the tools on the market, and find high volume stuff should be kept as native to the DB as possible if performance is key.
Click to expand...

I never said i was , did i?

We have written a very low level one purely for our needs.

Furthermore we do a lot of no sql storage and map reduce queries. postgres is just really for retention.
 
semaphore said:
I never said i was , did i?

We have written a very low level one purely for our needs.

Furthermore we do a lot of no sql storage and map reduce queries. postgres is just really for retention.
Click to expand...

semaphore said:
Yep, it is the first negative thing, apart from their entire framework.

We do with high volume transactions, entityframework was extremely poor candidate for us.
Click to expand...

Okay
 
Last edited:
Mike Smit said:
Okay
Click to expand...

You have this very arb fascination with assuming things. We trialed a few things before biting the bullet and writing our own layers, we really did not want to but landed up doing it.
 
semaphore said:
You have this very arb fascination with assuming things. We trialed a few things before biting the bullet and writing our own layers, we really did not want to but landed up doing it.
Click to expand...

Not wrong to "assume" you are using an ORM when you mention trying EF and high volume transactions in the same sentence. It implies you found/use another ORM for you high volume transactions.

You carry on though.
 
Okay well i cleared it up for you, i can understand how it could be difficult to understand the complexities of the English language.
 
Entity framework is great, and even with high volumes it does just perfect.

Do a couple of benchmarks first (with high volume transaction) using EF6 and .NET 4.5, then come back here and post your results..
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X